Резервное копирование баз данных Oracle: возможности и стратегии

Резервное копирование базы данных OracleРегулярное выполнение резервного копирования баз данных Oracle Database является одной из главных обязанностей администратора баз данных. Под резервным копированием подразумевается создание копий базы данных для обеспечения возможности ее воссоздания в будущем, если возникнет такая необходимость. Резервные копии лежат в основе всех процедур по восстановлению баз данных: в отсутствие резервных копий восстановление невозможно. Наилучшее, что может делать администратор баз данных для облегчения себе работы — это полагаться на уже проверенные и испробованные стратегии резервного копирования, поскольку чем больше времени тратится на планирование операций резервного копирования, тем меньше времени будет уходить на восстановление базы данных после катастрофического сбоя.

Выполнять операции резервного копирования баз данных Oracle можно двумя разными способами: либо с помощью поставляемой Oracle утилиты Recovery Manager (RMAN), либо с использованием соответствующих утилит операционной системы. Выполнение резервного копирования при помощи утилиты RMAN предоставляет гораздо больше преимуществ по сравнению с пользовательскими методами, предусматривающими применение утилит операционной системы.

Для хранения резервных копий администраторы баз данных довольно часто применяют ленточные устройства, потому что они удобны, к тому же на лентах резервные копии гораздо легче архивировать для длительного сбережения. При желании использовать с ленточными устройствами утилиту RMAN, необходимо дополнительно устанавливать специальное ПО уровня управления носителями (Medial Management Layer — MML). Компания Oracle предлагает свое собственное средство для управления носителями, которое называется Oracle Secure Backup (Безопасное резервное копирование Oracle) и поставляется бесплатно вместе с серверным программным обеспечением Oracle. 

Еще необходимо постоянно проверять наличие и действительность резервных копий для получения уверенности в том, что они правильны и годятся для выполнения восстановления. Итак, для начала давайте рассмотрим, что собой представляют процедуры резервного копирования баз данных Oracle и что с ними связано.

 

Резервное копирование баз данных Oracle

Процедуры резервного копирования баз данных применяются для предотвращения потери данных, поэтому очень важно иметь в распоряжении полноценную систему резервного копирования. Эти процедуры подразумевают создание копий ключевых файлов базы данных Oracle, к числу которых относятся файлы данных, управляющий файл и файлы архивных журналов повторного выполнения.

Копировать файлы базы данных позволяют процедуры физического резервного копирования. Выполнять процедуры физического резервного копирования можно двумя основными способами.

Утилита RMAN позволяет делать все то же, что и пользовательские методы резервного копирования, плюс предоставляет несколько дополнительных возможностей. Вдобавок она избавляет от необходимости отслеживать подвергаемые резервному копированию файлы данных и архивных журналов повторного выполнения, поскольку сама управляет все этой информацией.

После приобретения достаточных навыков по работе с  утилитой RMAN в режиме командной строки, можно переходить на использование графического интерфейса Database Control и работать с ней через него. 

Хотя цены на дисковые накопители продолжают снижаться, ленточные накопители по-прежнему остаются более дешевым вариантом для хранения больших объемов данных за пределами сайта. В случае использования RMAN, для сохранения резервных копий на ленточном устройстве требуется прибегать к помощи какого-то стороннего диспетчера носителей.

Прежде чем углубляться в механические детали процедур резервного копирования, необходимо ознакомится с определенными ассоциируемыми с ними терминами.

 

Важные термины, связанные с резервным копированием

Наличие четкого представления о том, какого типа бывают процедуры резервного копирования и какие понятия в них используются, является чрезвычайно важным для успешного выполнения восстановления базы данных. Поэтому далее вкратце описываются основные термины, ассоциируемые с процедурами резервного копирования баз данных Oracle.

 

Режимы ARCHIVELOG и NOARCHIVELOG

Oracle записывает все изменения, которые вносятся в находящиеся в памяти блоки данных, в оперативные журналы повторного выполнения (online redo logs), и делает это, как правило, перед их записью в файлы базы данных. Во время процесса восстановления Oracle использует зафиксированные в файлах этих журналов изменения для приведения базы данных в актуальное состояние. Oracle поддерживает два режима для управления такими файлами.

Производственные системы обычно запускают в режиме ARCHIVELOG по следующим причинам.

Вряд ли кому-нибудь приходилось сталкиваться с организацией, которую бы не волновала потеря ее важных производственных данных; следовательно, в режиме ARCHIVELOG функционируют почти все производственные базы данных. Режим NOARCHIVELOG используется только тогда, когда есть возможность восстановить данные из других источников, или когда база данных пока находится только на стадии разработки или тестирования и потому не нуждается в возможности восстановления ее данных с точностью до минуты. Хотя выполнение резервного копирования баз данных, функционирующих в режиме NOARCHIVELOG, и рассматривается в этой статье, основное внимание уделяется выполнению резервного копирования баз данных, которые работают в режиме ARCHIVELOG.


На заметку! В случае очень частого выполнения резервного копирования (с созданием инкрементных копий, например) или применения технологии создания мгновенного снимка при помощи утилиты, подобной Business Copy производства Hewlett-Packard, в базах данных некоторого типа может быть выгоднее обходится установкой режима NOARCHIVELOG.


 

Резервное копирование всей или части базы данных

Подвергать резервному копированию можно как всю базу данных, так и только ее часть, вроде входящего в ее состав табличного пространства или файла данных. Обратите внимание, что в случае, когда база данных функционирует в режиме NOARCHIVELOG, осуществлять резервное копирование лишь части базы данных, также называемое частичным резервным копированием (partial database backup), нельзя, если только все те табличные пространства и файлы, которые подлежат резервному копированию, не являются доступными только для чтения. Выполнять резервное копирование всей базы данных, также называемое полным резервным копированием (whole database backup), можно как в режиме ARCHIVELOG, так и в режиме NOARCHIVELOG.

Чаще всего выполняется полное резервное копирование. Оно предполагает копирование не только всех файлов данных, но и еще одного важного файла — управляющего. Без управляющего файла Oracle не будет открывать базу данных, поэтому для восстановления помимо резервных копий всех файлов данных необходимо также обязательно обладать и новейшей резервной копией управляющего файла.

 

Согласованное и несогласованное резервное копирование

Разница между согласованным и несогласованным резервным копированием очень проста. Согласованное резервное копирование (consistent backup) приводит к созданию согласованных резервных копий и не требует проводить процесс восстановления. При применении резервной копии для восстановления базы данных или ее части (например, табличного пространства или файла данных), сначала обычно требуется провести восстановление данных из резервной копии (т.е. процедуру RESTORE), а затем — восстановление работоспособности базы данных (т.е. процедуру RECOVER). В случае согласованного резервного копирования ни один из этих восстановительных шагов выполнять не требуется. В случае несогласованного резервного копирования (inconsistent backup) выполнение этих восстановительных шагов всегда является обязательным.

Oracle присваивает каждой транзакции уникальный системный номер изменения (System Change Number — SCN). Каждая фиксация, к примеру, будет приводить к увеличению этого номера. Всякий раз, когда Oracle устанавливает контрольную точку, все изменившиеся данные в оперативных файлах данных записываются на диск. И всякий раз, когда это происходит, Oracle выполняет обновление контрольной точки потока (thread checkpoint) в управляющем файле. Во время этого обновления Oracle делает так, чтобы все доступные для чтения и записи файлы данных и управляющие файлы согласовались с одним и тем же SCN-номером. База данных считается согласованной тогда, когда SCN-номера, хранимые в заголовках всех файлов данных, являются идентичными и совпадают с информацией о заголовках файлов данных, которая содержится в управляющих файлах. Главное запомнить, что один и тот же SCN-номер должен обязательно присутствовать во всех файлах данных и управляющем файле (или файлах). Присутствие идентичного SCN-номера означает, что в файлах данных содержатся данные за один и тот же промежуток времени. Если данные являются согласованными, никакие шаги по восстановлению после возврата (или копирования) набора файлов резервных копий на прежнее место не понадобятся.

Для создания согласованной резервной копии базу данных необходимо либо закрывать (обычной командой SHUTDOWN или SHUTDOWN TRANSACTIONAL, но не командой SHUTDOWN ABORT), либо останавливать (с помощью команды аккуратного завершения работы) и запускать снова в режиме монтирования.

При выполнении несогласованного резервного копирования получается, что в файлах резервной копии содержатся данные за разные промежутки времени. Дело в том, что работу большинства производственных систем не допускается прерывать для проведения согласованного резервного копирования. Вместо этого необходимо, чтобы эти базы данных работали 24 часа в сутки 7 дней в неделю. Это, следовательно, означает, что резервное копирование этих баз данных должно выполняться в оперативном режиме, т.е. пока они остаются открытыми для транзакций. Изменение файлов данных пользователями во время проведения резервного копирования как раз и приводит к получению несогласованных резервных копий. Выполнение несогласованного резервного копирования не означает получение каких-то неправильных резервных копий. Однако во время восстановления одного только возврата таких резервных копий на прежнее место не достаточно. Помимо возврата их на прежнее место требуется также обязательно применить все архивные и оперативные журналы повторного выполнения, которые были созданы в промежутке с момента выполнения резервного копирования и до момента, до которого необходимо восстановить базу данных. Oracle будет считывать эти файлы и автоматически применять к файлам этих резервных копий все необходимые изменения.

Поскольку при открытой базе данных можно осуществлять только несогласованное резервное копирование, для большинства производственных баз данных применяются стратегии именно с процедурами несогласованного резервного копирования в основе.

 

Резервное копирование открытой и закрытой базы данных

Резервное копирование открытой базы данных (open backup), также называемое оперативным (online backup) или горячим резервным копированием (hot/warm backup), подразумевает создание резервных копий при открытой и доступной для пользователей базе данных. Выполнять оперативное резервное копирование всей базы данных (равно как и только принадлежащего ей табличного пространства или файла данных) можно только в том случае, если база данных функционирует в режиме ARCHIVELOG. Проводить его, когда база данных функционирует в режиме NOARCHIVELOG, нельзя.

Резервное копирование закрытой базы данных (closed backup), также называемое холодным резервным копированием (cold backup), подразумевает создание резервных копий при закрытой (остановленной) базе данных. Такое резервное копирование всегда приводит к созданию согласованных резервных копий, если только база данных не была остановлена командой SHUTDOWN ABORT.


На заметку! Следует иметь в виду, что в случае выполнения резервного копирования при открытой (находящейся в оперативном режиме) базе данных или при закрытой (находящейся в автономном режиме), но не согласованной базе данных, может быть необходимо использовать архивные журналы повторного выполнения для придания базе данных согласованного вида.


Решение о том, следует выполнять резервное копирование при закрытой или при открытой базе данных, принимается в зависимости от имеющихся бизнес-требований. Именно бизнес-требования диктуют уровни готовности, которые затем включаются в соглашения об уровне обслуживания (Service-Level Agreement — SLA). Если по соглашению об уровне обслуживания база данных должна находиться в работоспособном состоянии 24 часа 7 дней в неделю, тогда следует применять процедуры оперативного резервного копирования. Если же организация допускает выделение окна для проведения резервного копирования, которое позволит временно переводить базу данных в автономный режим, тогда вполне можно планировать проведение процедур резервного копирования закрытой базы данных. Частота проведения этих процедур и количество журналов повторного выполнения, создаваемых базой данных, влияют на то, сколько времени будет занимать ее восстановление. В случае выполнения резервного копирования закрытой базы данных раз в неделю, например, может потребоваться применять к резервной копии базы данных во время восстановления архивные журналы, созданные вплоть до шести дней назад (если брать самый худший вариант).

 

Физическое и логическое резервное копирование

С технической точки зрения процедуры резервного копирования Oracle можно поделить на логические и физические. Под логическим резервным копированием (logical backup) подразумевается создание резервных копий с помощью утилиты Data Pump Export, которые содержат логические объекты наподобие таблиц и процедур. Эти резервные копии сохраняются в особом двоичном формате, и данные из них могут извлекаться только посредством утилиты Data Pump Import.

Под физическим резервным копированием (physical backup) подразумевается создание резервных копий ключевых файлов базы данных Oracle, т.е. файлов данных, файлов архивных журналов повторного выполнения и управляющих файлов. Эти резервные копии могут сохраняться как на дисковых, так и на ленточных накопителях.

В этой статье основное внимание уделяется процедурам создания физических резервных копий, поскольку они играют очень важную роль в стратегии восстановления Oracle в случае серьезной потери данных. Логические резервные копии являются лишь дополнением, а не альтернативой физическим.

 

Уровни резервного копирования

Ниже перечислены уровни, на которых допускается выполнять резервное копирование баз данных Oracle.

 

Рекомендации по резервному копированию

Как бы ни выглядело соглашение об уровне обслуживания и требования к восстановлению, есть некоторые общие рекомендации касательно процесса резервного копирования, которые будут помогать избегать восстановления в большинстве случаев. В конце концов, наилучшей стратегией для восстановления, несомненно, является предотвращение возникновения необходимости в его выполнении за счет настройки надежной системы резервного копирования и защиты данных.

Итак, в том, что касается резервного копирования, рекомендуется проводить следующие мероприятия.


На заметку! В отличие от ситуации с файлами оперативных журналов повторного выполнения, экземпляр Oracle будет останавливаться как при невозможности выполнить запись в один из мультиплексированных управляющих файлов из-за отказа диска, так и при нехватке места на том диске, где находится управляющий файл.


 

Тестирование процедур резервного копирования

Очень часто администратор баз данных впервые обнаруживает недостатки стратегии резервного копирования уже во время проведения стрессового процесса по восстановлению производственной базы данных. Большая часть проблем во время восстановления возникает из-за неправильного или вообще не проводившегося планирования и тестирования стратегии резервного копирования и восстановления. Узнавать, подлежит ли база данных восстановлению, уже по ходу осуществления среди ночи попытки восстановить ее, точно не является наилучшим временем. Во избежание катастрофического опыта с восстановлением, каждый администратор баз данных должен создавать и тестировать планы по проведению процедур резервного копирования и восстановления.

Кроме того, администратору баз данных нужно всегда удостоверяться в действительности резервных копий и том, являются ли они пригодными для чтения, а также выполнять проверку на предмет наличия повреждений в подвергаемых резервному копированию файлах для исключения невозможности проведения восстановления из-за поврежденных файлов. Как утилита RMAN, так и пользовательские методы резервного копирования предусматривают способы для выполнения проверки на предмет повреждения блоков данных. И, наконец, последнее, что необходимо делать администратору баз данных — обязательно регулярно тестировать процессы восстановления для всех ключевых баз данных.

 

Поддержание запасного набора

Всегда стоит поддерживать в оперативном режиме запасной набор для обеспечения возможности более быстрого выполнения восстановления. В состав запасного набора (redundancy set) должно входить следующее:

Вдобавок в состав запасного набора могут включаться файлы SPFILE, init.ora, listener.ora и tnsnames.ora.

Наличие такого запасного набора гарантирует возможность выполнения восстановления после отказа носителя из-за потери любого возможного файла: файла данных, управляющего файла или оперативного журнала повторного выполнения. Этот набор должен обязательно храниться отдельно от файлов данных, файлов оперативных журналов повторного выполнения и управляющих файлов, т.е. размещаться на отдельных физических томах и системах RAID. Подобное отделение запасного набора от активных файлов базы данных полностью исключает вероятность потери в будущем каких-то данных из-за неполадок с носителем.

Идеальным местом для размещения запасного набора является область пакетного восстановления, о которой будет рассказываться чуть позже в этой главе, в разделе “Область пакетного восстановления”. Размещение запасного набора в этой области позволяет поддерживать его в одном месте на диске и автоматически управлять занимаемым им пространством, а также сокращать время восстановления, благодаря хранению всех необходимых входящих в его состав резервных копий на самом диске.

 

Стратегии резервного копирования

То, что со временем будут возникать проблемы, связанные с носителями данных, можно воспринимать как должное. Чтобы быть готовым к такому развитию событий, необходимо разработать стратегию. То, как должна выглядеть эта стратегия по резервному копированию, очень сильно зависит от принятого соглашения по уровню обслуживания, от размера баз данных, от объема вносимых в данные изменений, количества доступного места на дисках и прочих факторов.

 

Соглашения об уровне обслуживания

Сегодня IT-отдельны довольно часто заключают со своими клиентами формальные соглашения по уровню обслуживания (Service-Level Agreements — SLA). Эти соглашения, по сути, представляют собой способы формулирования ожиданий касательно готовности и производительности базы данных, а также других компонентов, например, сети. В них обычно оговариваются следующие факторы:

Период готовности баз данных задается в SLA-соглашениях очень четко вместе с окнами обслуживания и планируемым временем восстановления в случае нескольких неподдающихся расчету простоев (вроде простоя из-за отказа диска). Понятие готовности (uptime) является довольно запутанным — при готовности 99%, например, в год все равно получается почти четыре полных дня простоя. Независимо от того, подходит ли организации такой вариант или она желает, чтобы степень готовности составляла 99,999% (это подразумевает только пять минут простоя), этот момент должен обязательно оговариваться и фиксироваться в SLA-соглашения очень четко.

Типичное SLA-соглашение по операциям с базой данных может выглядеть примерно так, как показано ниже (здесь приведена только часть соглашения).

Стандартные услуги по обслуживанию. Поставщик услуг обязуется обеспечить и предоставлять доступ к производственным средам, описанным ниже образом.

a) Производственные среды среднего звена.

(1) Подлежащие обслуживанию приложения

Системы финансовой информации, которые следует включить:

ПЕРЕЧЕНЬ ФИНАНСОВЫХ ПРИЛОЖЕНИЙ

Другие приложения этого звена

(2) Часы доступности

В интерактивном режиме: понедельник — пятница* 07:00-17:00*. суббота, воскресенье и праздники не считаются. * Приложение будет обслуживаться через Web по системе 24×7×365 БЕЗ УЧЕТА планируемых периодов обслуживания (см. ниже). В пакетном режиме: не поддерживается. Обслуживание: каждый месяц, а именно — в последние выходные каждого месяца.

(3) Требования к стандартному обслуживанию/услугам

Все системы и приложения, перечисленные в параграфе (1), должны быть доступны 98% из общего времени, описанного выше в параграфе (2). Отдел информационных систем обеспечит отдел финансов средством для наблюдения за процентными показателями доступности.

(4) Обработка данных будет ограничиваться лишь теми функциональными возможностями или обработкой, которая была проведена на момент передачи операций отделу информационных служб.

b) …


На заметку! Кроме того, в SLA-соглашениях оговариваются причины возможных перерывов в обслуживании и ожидания касательно его возобновления. Если прерывание обслуживания происходит не из-за неполадок с базами данных, очевидно, что в игру вступают другие факторы, наподобие неполадок на сервере и в сети. Возможные причины неполадок с базами данных и время, которое потребуется на выполнение восстановления после каждой из них, однако, тоже нужно обязательно оговаривать. Общее время, необходимое для выполнения любого процесса восстановления, конечно же, будет состоять из времени, требуемого для выполнения восстановления утраченных или поврежденных файлов из резервных копий, и времени, требуемого для восстановления работоспособности базы данных. 


Вид стратегии резервного копирования и восстановления, которую нужно разрабатывать, очень сильно зависит от указываемого в SLA-соглашении уровня готовности. Этот уровень готовности отражает то, насколько быстро должно осуществляться восстановление базы данных. Если в SLA-соглашении говорится, что восстановление базы данных может занимать целый день, тогда выполнять еженощное оперативное резервное копирование вовсе необязательно. Возможно, будет лучше выполнять вместо него еженедельное холодное резервное копирование (если SLA-соглашение допускает простой базы данных по подобной причине), а если SLA-соглашение требует готовности 99,999%, тогда — инвестировать в RAC (Oracle Real Application Clusters), например.

Обычно готовность и стоимость зависят друг от друга прямо пропорционально. А как быть, если окажется, что заставить главный сервер функционировать очень долго нет возможности? В таком случае, пожалуй, не помешает подготовить на смену главной резервную базу данных.

 

Планирование стратегии резервного копирования

Одной универсальной стратегии, которая работала бы для всех организаций, не существует. Лучше планировать использование области пакетного восстановления, о которой будет рассказываться в следующем разделе, поскольку это позволит не выполнять восстановление с ленты во многих случаях и тем самым экономить ценное время, а так-же избавит от необходимости вручную удалять устаревшие файлы резервных копий.

Эффективная стратегия резервного копирования должна подразумевать две следующих важных вещи.

Если ожидается внесение небольшого количества изменений в данных, лучше использовать процедуры инкрементного резервного копирования, поскольку создаваемые в результате резервные копии не будут занимать много места. Создание инкрементных резервных копий в виде части стратегии резервного копирования будет сокращать время, необходимое для применения данных повторного выполнения во время восстановления. Однако если ожидается частое изменение большинства блоков данных, инкрементные резервные копии будут получаться довольно большими. Поэтому в таком случае лучше планировать создание полной копии образа базы данных через регулярные интервалы времени.

Частота, с которой должны выполняться процедуры резервного копирования, и то, должны ли и как именно применяться операции инкрементного резервного копирования, зависит от показателя допустимого среднего времени восстановления ( Mean Time To Recover — MTTR). Например, можно реализовать трехуровневую схему резервного копирования с ежемесячным выполнением полного резервного копирования на уровне 0, еженедельным выполнением кумулятивного резервного копирования на уровне 1 и ежедневным выполнением дифференциального резервного копирования на уровне 1. (О том, что конкретно собой представляют эти уровни и кумулятивное и дифференциальное резервное копирование, будет рассказываться позже в этой главе, при рассмотрении команд утилиты RMAN, в разделе “Инкрементное резервное копирование”). В случае применения такой стратегии базу данных наверняка удастся полностью восстановить без применения журналов повторного выполнения более чем однодневного срока давности.

Для минимизации MTTR можно воспользоваться функцией резервного копирования с инкрементным обновлением (incrementally updated backups). Ежедневное выполнение сценария, описанного в разделе “Резервное копирование с инкрементным обновлением” далее в этой главе, по сути, позволит восстанавливать данные до состояния, в котором они находились на любой момент времени в прошлом (PITR), в пределах 24 часов.

 

График резервного копирования, предлагаемый для баз данных с нечастым внесением изменений

В рассматриваемом здесь примере предполагается, что размер области пакетного восстановления допускает хранение в ней инкрементных резервных копий сроком за три дня; для политики сохранности установлено значение REDUNDANCY 1, подразумевающее хранение только одного набора резервных копий под рукой; команда RECOVER COPY предполагает использование резервной копии всей базы данных уровня 0. Для сохранения архивных журналов и инкрементных резервных копий, созданных после SYSDATE-3, применяется следующий сценарий: 

RECOVER COPY OF DATABASE TAG "whole_db_copy" UNTIL TIME 'SYSDATE-3';
BACKUP INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE;

Предположим, что этот сценарий впервые запускается в воскресенье, 20 июля 2008 г., и принято решение о том, что в области пакетного восстановления должны храниться резервные копии, а также файлы данных и архивные журналы повторного выполнения не более чем трехдневного срока давности. Тогда любые резервные копии и архивные журналы повторного выполнения сроком старше трех дней будут автоматически удаляться, если возникнет необходимость в выделении в области пакетного восстановления дополнительного пространства для новых файлов. Следовательно, в каждый из последующих дней содержимое области пакетного восстановления будет выглядеть так, как описано ниже.

График резервного копирования, предлагаемый для баз данных с частым внесением изменений

Если база данных часто подвергается изменениям, от инкрементных резервных копий будет мало толку. В таком случае гораздо лучше делать полную резервную копию базы данных через регулярные интервалы времени. Ниже показан пример команды, которую можно использовать для еженедельного выполнения полного резервного копирования: 

RMAN> BACKUP DATABASE TAG "weekly_full_bkup";

Предположим, что эта команда резервного копирования настраивается так, чтобы она выполнялась раз в неделю, в воскресенье ночью, и что впервые она запускается в воскресенье, 20 марта. Тогда содержимое области пакетного восстановления будет выглядеть так.

Теперь, когда мы рассмотрели основные понятия и стратегии резервного копирования, можно переходить к изучению технических деталей процедур резервного копирования баз данных Oracle. Начнем мы с изучения области пакетного восстановления.

 

Вас заинтересует / Intresting for you:

Резервное копирование и восста...
Резервное копирование и восста... 7114 просмотров Albert Tue, 21 Nov 2017, 13:18:46
Пользовательские методы резерв...
Пользовательские методы резерв... 11945 просмотров Дэн Tue, 21 Nov 2017, 13:18:05
Ищем и исправляем ошибки в баз...
Ищем и исправляем ошибки в баз... 6770 просмотров Александров Попков Tue, 21 Nov 2017, 13:18:05
Разработка стратегий резервног...
Разработка стратегий резервног... 2087 просмотров Bella Tue, 21 Nov 2017, 13:28:01
Печать
Войдите чтобы комментировать

apv аватар
apv ответил в теме #8704 6 года 6 мес. назад
Внимание, вопрос! Есть ли в ваших компаниях разработанный и действующий документ по стратегии резервирования и восстановления базы данных в нештатных ситуациях? Как действуете в случае аварий? Сразу полагаетесь на свой опыт, открываете мануалы или есть все же такой пошаговый документ, как палочка-выручалочка?)