Копирование файлов в oracle
День жестянщика
Начнем с разбора ошибок, обычно допускаемых новичками, впервые сталкивающимися с Oracle. Обработка данных мониторинга может предусматривать достаточно сложную логику, но об этом мы будем говорить позже. Пока просто попробуем сохранить полученные данные в следующую таблицу:
Автоматизируем генерацию ID триггером, как это советуют многие online-источники:
И начнем кодить:
Запустив на выполнение этот код, получаем количество вставок, выполняемых в секунду:
Вроде бы неплохо. Но явно меньше 9000. Что мы делаем не так?
Довольно многое (пункты даны в порядке убывания влияния на производительность):
- Мы провоцируем hard parse, передавая каждый раз новый вариант запроса (у такого подхода есть и другие недостатки, такие как возможность получения sql injection или заполнение библиотечного кэша, но нам хватит и первой причины, чтобы больше никогда так не делать)
- Создавая сессию, JDBC по умолчанию устанавливает включенной настройку auto commit (ниже мы посмотрим, к чему это приводит с точки зрения производительности)
- Вызов триггера приводит к переключению контекстов SQL и PL/SQL (это не очень существенно при вставке одиночных записей, но весьма заметно при выполнении массовых вставок)
- При массовой вставке, sequence имеет смысл кэшировать (но это не наш случай, поскольку мы вставляем по одной записи из одного потока)
Хочу обратить внимание, что теперь текст запроса заканчивается точкой с запятой. По ней Oracle определяет, что мы собираемся выполнять не SQL, а PL/SQL-код.
Запускаем на выполнение:
Лучше, но все равно мало.
Быстрее, выше, сильнее!
Что можно сделать чтобы ускорить вставку? Для начала стоит отключить auto commit. При работе с Oracle, слишком частая фиксация транзакций это не только накладные расходы, но и (в некоторых случаях) хороший шанс спровоцировать ошибку ORA-01555.
Разумеется, размер транзакции должен определяться бизнес логикой. Если бизнес-логика требует фиксировать каждую одиночную вставку в отдельной транзакции, то именно так и придется делать. Но (на мой взгляд) лучше управлять фиксацией транзакций самостоятельно чем отдавать этот важный вопрос на откуп JDBC.
Какого размера должна быть транзакция при массовой вставке данных? Универсального ответа, разумеется, нет. До определенного предела, действует правило — чем больше размер транзакции, тем быстрее сохраняются данные. В этой статье я не буду экспериментировать с размером транзакций, а просто выполню вставку всех строк в одной транзакции.
Результат улучшился почти в два раза:
Чтобы улучшить его еще больше, можно вспомнить о временных таблицах:
Поскольку мы убрали из таблицы столбец id, внесем изменения в реализацию пакета:
Так как вставка данных во временную таблицу не фиксируется в REDO-логе (не требуется восстанавливать эти данные при сбое), это ведет к закономерному снижению накладных расходов:
Если использовать DML-запросы вместо обращения к пакету, можно довести это значение до 2000. Неужели это предел?
Разумеется нет! Сейчас, когда мы практически свели на нет накладные расходы связанные с фиксацией транзакций, мы упираемся в другое бутылочное горлышко — в количество запросов, передаваемых по сети. Чтобы решить эту проблему, были разработаны bulk-запросы, позволяющие передавать несколько однотипных изменений в одном запросе.
Вносим необходимые изменения в код:
Запускаем на выполнение:
И не замечаем никакой разницы. Почему?
Дело в том, что bulk-и работают только для DML-запросов (insert, update, delete). Если мы пытаемся вызывать bulk-запросом хранимую процедуру, JDBC эмулирует bulk, отсылая по сети ровно то-же самое количество запросов, что было бы без него.
Исправим этот досадный промах:
И запустим код на выполнение снова:
Ха, мы определенно идем на рекорд! Доведя BULK_SIZE до 100, можно получить и вовсе волшебное значение:
Итак, мы научились очень быстро вставлять данные во временную таблицу и… терять их при commit-е, так ничего с ними и не сделав.
Где логика?
Сейчас добавим. Для начала спроектируем схему данных:
Пусть у нас имеется список устройств test_device и список параметров test_parameter. Текущее значение каждого параметра будет храниться в test_state, а в test_history будем записывать хронологию изменения значений. Для упрощения кода, будем считать что параметры не могут принимать значение null.
Кроме того, мы будем обрабатывать значения двух типов, заданных в test_parameter_type. Тип параметра будет определять, в каком случае выполняется добавление записи в test_history:
- Тип 'default' будем использовать (в частности) для хранения оперативного состояния устройств, запись в test_history добавляется при любом изменении значения
- Тип 'uptime' используем для хранения времени безостановочной работы, значение в test_history добавляется из test_state в том случае, если новое значение меньше предыдущего (то есть устройство перезагружалось)
Далее, добавим в пакет процедуру массовой обработки значений:
Можно заметить, что запросы получились не простые, но сложные запросы это именно то, что Oracle умеет выполнять лучше всего.
Внесем изменения в код:
и запустим его на выполнение:
Увы, чуда не произошло. Необходимость сохранения данных в журналируемых таблицах сыграла свою роль. Но 5000 записей в секунду, в любом случае, гораздо лучше 600. Теперь мы знаем максимальную скорость, с которой мы можем сохранять данные в Oracle (естественно на выбранном для тестов сервере).
Если нам требуется более высокая скорость обработки или меньшее время обработки каждого запроса, имеет смысл смотреть с сторону InMemory DB. Но это тема для другого разговора.
Готовы ли вы потерять свои данные?
Можно заметить, что мы добились высокой скорости загрузки данных в обмен на риск потери той части данных, сохранение которой не зафиксировано. При проектировании приложения, этот риск можно свести к минимуму, но полностью избавиться от него нельзя.
Использование InMemory или NoSQL DB не изменит эту картину радикально. Хотя эти СУБД предусматривают защиту данных (например при помощи REDO-лога в случае Oracle TimesTen), добиться максимальной производительности можно только отключив эту защиту (такая возможность предоставляется очень часто).
Приходится выбирать, что важнее — обеспечить максимально возможную сохранность данных или максимальную производительность? Ответ на этот вопрос может дать только постановщик задачи. Мы же, со своей стороны, можем воплотить его требования в жизнь, добиваясь максимальной эффективности от того инструмента, который используем.
Файлы можно копировать непосредственно между базами данных через сеть Oracle Net, не используя команд операционной системы или утилит вроде FTP. С помощью пакета DBMS_FILE_TRANSFER выполняется копирование двоичных файлов в пределах одного сервера или передача их между серверами. Процедура COPY_FILE служит для копирования файлов в пределах локальной системы, процедура GET_FILE — для копирования файлов с удаленного сервера на локальный и процедура PUT_FILE — для чтения и копирования локального файла на удаленную файловую систему. Далее приводится краткое описание ключевых процедур нового пакета.
COPY_FILE
Процедура COPY_FILE позволяет копировать двоичные файлы из одного места в другое на одном и том же или на разных серверах. Прежде чем вы можно будет копировать эти файлы, необходимо создать объекты исходного и целевого каталога, как показано ниже:
После создания исходного и целевого каталогов можно применять процедуру COPY_FILE для копирования файлов:
Копирование файлов в локальной системе
Копирование файлов между каталогами одного и того же сервера выполняется с помощью процедуры COPY_FILE из пакета DBMS_FILE_TRANSFER . Предположим, что необходимо скопировать файл по имени example.txt из каталога /u01/app/oracle в каталог /u01/app/Oracle/dba. Для этого потребуется выполнить следующие шаги.
- Создайте объект исходного каталога, указывающий на исходный каталог (source_dir):
- Создайте объект целевого каталога, указывающий на целевой каталог (dest_dir):
- Воспользуйтесь процедурой COPY_FILE для копирования файла example.txt (DESTINATION_FILE_NAME) из исходного каталога в целевой (при желании, изменив его имя в процессе копирования):
Если теперь заглянуть в целевой каталог (/u01/app/oracle/test), там будет находиться копия исходного файла из исходного каталога (/u01/app/oracle).
Совет. Чтобы выполнить процедуру DBMS_FILE_TRANSFER.COPY_FILE, необходимо иметь привилегию READ в исходном каталоге и привилегию WRITE — в целевом.
Новый мастер OEM Database Control Load Data Wizard автоматизирует процесс создания управляющих файлов SQL*Loader. Вы специфицируете файлы данных и предоставляете информацию о их структуре, в Load Data Wizard использует ее для автоматической генерации контрольного файла SQL*Loader, а также создания задания SQL*Loader для загрузки файла данных в базу.
Инкрементальное резервное копирование
Чтобы ускорить восстановление на точку, хотелось бы иметь возможность выполнять резервное копирование как можно чаще, но при этом не занимать лишнего места на дисках и не нагружать базу задачами резервного копирования.
Решение задачи – инкрементальное резервное копирование, то есть копирование только тех страниц данных, которые изменились с момента предыдущего резервного копирования.
Инкрементальное резервное копирование имеет смысл только для СУБД, использующих изменяемые структуры данных.
Инкремент может отсчитываться как от полной резервной копии (кумулятивная копия), так и от любой предыдущей копии (дифференциальная копия).
К сожалению, единой терминологии не существует, и разные производители используют разные термины:
Дифференциальная | Кумулятивная | |
---|---|---|
Oracle | Differential | Cumulative |
PostgresPro | Incremental | — |
Microsoft SQL Server | — | Differential |
IBM DB2 | Delta | Incremental |
MySQL Enterprise | Incremental | Differential |
Percona Server | Incremental |
При наличии инкрементальных копий процесс восстановления на точку выглядит следующим образом:
- восстанавливается последняя полная резервная копия, сделанная до момента восстановления;
- поверх полной копии восстанавливаются инкрементальные копии;
- накатываются журналы с точки начала резервного копирования до точки восстановления.
Есть три способа создания инкрементальной копии:
- создание полной копии и вычисление разницы с предыдущей полной копией;
- разбор журналов, создание списка изменённых страниц и резервирование страниц, включённых в список;
- запрос изменённых страниц в базе данных.
Второй и третий способ отличаются механизмом определения списка изменённых страниц. Разбор журналов более ресурсоёмкий, плюс для его реализации необходимо знать структуру журнальных файлов. Спросить у самой базы, какие именно страницы изменились, проще всего, но для этого ядро СУБД должно иметь функциональность отслеживания изменённых блоков (block change tracking).
Впервые функциональность инкрементального резервного копирования была создана в ПО Oracle Recovery Manager (RMAN), появившемся в релизе Oracle 8i. Oracle сразу реализовал отслеживание изменённых блоков, поэтому необходимости в разборе журналов нет.
PostgreSQL не отслеживает изменённые блоки, поэтому утилита pg_probackup, разработанная российской компанией Postgres Professional, определяет изменённые страница путём анализа журнала. Однако компания поставляет и СУБД PostgresPro, которая включает расширение ptrack, отслеживающее изменение страниц. При использовании pg_probackup с СУБД PostgresPro утилита запрашивает изменённые страницы у самой базы – точно так же, как и RMAN.
Microsoft SQL Server так же, как и Oracle, отслеживает изменённые страницы, но команда BACKUP позволяет делать только полные и кумулятивные резервные копии.
В DB2 есть возможность отслеживания измененных страниц, но по умолчанию она выключена. После включения DB2 позволит делать полные, дифференциальные и кумулятивные резервные копии.
Важное отличие описанных в этом разделе средств (кроме pg_probackup) от файловых средств резервного копирования в том, что они запрашивают образы страниц у базы данных, а не читают данные с диска самостоятельно. Недостаток такого подхода – небольшая дополнительная нагрузка на базу. Однако этот недостаток с лихвой компенсируется тем, что прочитанная страница всегда корректна, поэтому нет необходимости во включении на время резервного копирования особого режима журналирования.
Ещё раз обратите внимание, что наличие инкрементальных копий не отменяет требований к наличию журналов для восстановления на произвольную точку во времени. Поэтому в промышленных базах данных журналы постоянно переписываются на внешний носитель, а резервные копии, полные и/или инкрементальные, создаются по расписанию.
Наилучшей на сегодня реализацией идеи инкрементального резервного копирования является программно-аппаратный комплекс (в терминологии Oracle – engineered system) Zero Data Loss Recovery Appliance – специализированное решение Oracle для резервного копирования собственной БД. Комплекс представляет собой кластер серверов с большим объёмом дисков, на которые установлена модифицированная версия ПО Recovery Manager и может работать как с другими программно-аппаратными комплексами Oracle (Database Appliance, Exadata, SPARC Supercluster), так и с базами Oracle на традиционной инфраструктуре. В отличие от «обычного» RMAN, в ZDLRA реализована концепция «вечного инкремента» (incremental forever). Система единственный раз создаёт полную копию базы данных, а потом делает только инкрементальные копии. Дополнительные модули RMAN позволяют объединять копии, создавая новые полные копии из инкрементальных.
К чести российских разработчиков нужно заметить, что и pg_probackup умеет объединять инкрементальные копии.
В отличие от многих похожих вопросов, вопрос «какой метод резервного копирования лучше» имеет однозначный ответ – лучше всего родная для используемой СУБД утилита, обеспечивающая возможность инкрементального копирования.
Для администратора БД гораздо более важными являются вопросы выбора стратегии резервного копирования и интеграция средств резервирования баз данных в корпоративную инфраструктуру. Но эти вопросы выходят за рамки данной статьи.
Восстановление на точку
Резервная копия позволяет восстановить состояние базы данных на момент, когда завершилась команда возврата из режима резервного копирования. Однако авария, после которой потребуется восстановление, может произойти в любой момент. Задача восстановления состояния БД на произвольный момент называется «восстановлением на точку» (point-in-time recovery).
Чтобы обеспечить такую возможность, следует сохранять журналы БД начиная с момента окончания резервного копирования, а в процессе восстановления продолжить применять журналы к восстановленной копии. После того, как БД восстановлена из резервной копии на момент окончания копирования, состояние базы (файлов и кэшированных страниц) гарантированно корректно, поэтому особый режим журналирования не нужен. Применяя журналы до нужного момента, можно получить состояние базы данных на любую точку во времени.
Если скорость восстановления резервной копии ограничена лишь пропускной способностью диска, то скорость применения журналов обычно ограничена производительностью процессора. Если в основной базе данных изменения происходят параллельно, то при восстановлении все изменения выполняются последовательно – в порядке чтения из журнала. Таким образом время восстановления линейно зависит от того, насколько далеко точка восстановления отстоит от точки окончания резервного копирования. Из-за этого приходится довольно часто делать полные резервные копии – минимум раз в неделю для баз с небольшой транзакционной нагрузкой и до ежедневного копирования высоконагруженных баз.
Передача файла в другую базу
Пакет DBMS_FILE_TRANSFER позволяет пересылать копии файлов с сервера на удаленный сервер посредством процедуры PUT_FILE. Вы выполняете те же шаги, что описаны в предыдущем разделе, но используете дополнительный параметр DESTINATION_DATABASE, чтобы указать удаленный сервер:
Совет. Прежде чем использовать процедуру PUT_FILE для пересылки файлов на удаленный сервер, следует удостовериться в существовании в локальной базе связи удаленной базы данных.
Процедура PUT_FILE сначала читает указанный файл на локальном сервере, а затем создает копию этого файла на удаленном сервере, который указывается в параметре DESTINATION_DATABASE. Таким образом, исходный каталог находится на локальном сервере, а удаленный каталог — на удаленном сервере.
Процедура GET_FILE является аналогом процедуры PUT_FILE и позволяет копировать файлы с удаленного сервера на локальный сервер. В этой процедуре целевой каталог и целевой файл находятся на локальном сервере, а исходный файл и каталог — на удаленном сервере. Вот структура GET_FILE:
Можно работать с любыми типами файлов, которые разрешены администратором сервиса (пользователь, который управляет Oracle Content Management ). Можно загружать и выгружать документы, видеофайлы, изображения и графику – все, что может потребоваться для проектов.
Хотя это не обсуждалось в данной теме, вы также можете загрузить шаблоны и другие файлы, необходимые для своих веб-сайтов. Сюда входят цифровые активы, такие как изображения или видео, которые могут потребоваться на вашем веб-сайте. Управление этими элементами осуществляется в диспетчере цифровых активов. Также можно создать элементы контента, представляющие собой блоки контента, подобранного по типам контента, созданным администратором.
В этой теме обсуждаются следующие области:
Смена вида страницы "Документы"
Вид страницы "Документы" можно изменить в соответствии со своими потребностями.
Задача | Описание |
---|---|
Фильтрация вида файлов и папок | Чтобы отфильтровать то, что отображается, откройте меню "Документы". Вы можете видеть все элементы, принадлежащие вам элементы, общедоступные элементы, избранное или элементы, перемещенные в корзину. |
Сортировка файлов и папок | Чтобы сортировать список своих файлов и папок, нажмите вариант сортировки ("Имя" или "Последнее обновление") в правом верхнем углу списка файлов. |
Изменение вида файлов и папок | Файлы и папки можно представить в виде списка, сетки или таблицы. Чтобы изменить вид, нажмите на значок меню ( ) (справа от меню сортировки) и выберите нужный вид. |
Действия с папкой
В таблице ниже перечислены распространенные действия, которые можно выполнять с папками, вызывая из строки меню или контекстного меню. В зависимости от ширины окна браузера в строке меню могут отображаться не все пункты меню. Если отображаются не все пункты, нажмите кнопку Дополнительно в строке меню. Отобразятся скрытые элементы.
Если назначенная вам роль не позволяет выполнять определенные действия или эти действия недоступны для вас по другой причине, соответствующий пункт меню будет неактивен.
Если скопировать папку в то же самое местоположение, копия переименовывается с добавлением номера к имени. Пример: Продажи(2) .
Так же как и при работе на локальном компьютере, удаленные папки перемещаются в папку "Корзина" в облаке. Если вы изменили свое решение, перейдите в папку "Корзина" и восстановите удаленный объект. Чтобы проверить корзину, в меню "Документы" выберите Корзина .
Удаленные объекты находятся в корзине до тех пор, пока не наступит одно из следующих событий:
- Элемент окончательно удален.
- Квота корзины превышена.
- Автоматическая очистка корзины — выполняется по расписанию, заданному администратором сервиса, который управляет экземпляром сервиса в вашей организации.
Действия с файлами
В таблице ниже перечислены распространенные действия, которые можно выполнять с файлами, вызывая их из панели действий или контекстного меню. В зависимости от ширины окна браузера, на панели действий могут отображаться не все пункты меню. Если отображаются не все пункты, нажмите Дополнительно на панели действий, чтобы отобразить скрытые элементы. Некоторые действия доступны через боковую панель, также можно получить к ним доступ, нажав на , чтобы открыть боковую панель или выбрав боковую панель на панели действий.
Если назначенная вам роль не позволяет выполнять определенные действия или эти действия недоступны для вас по другой причине, соответствующее действие будет недоступно на панели действий.
Задача | Описание |
---|---|
Загрузка файла | Перейдите к месту загрузки файла, выберите Загрузить в контекстном меню или нажмите на панели действий, затем выберите файл на компьютере. |
Создание нового файла Microsoft Office | Перейдите в то местоположение, в котором требуется создать новый файл, нажмите Создать , а затем выберите тип создаваемого файла Microsoft Office. |
Просмотр файла | Выберите файл, затем выберите Просмотреть в контекстном меню или нажмите на панели действий. |
Если вы выбрали файл Microsoft Office и системный администратор включил интеграцию с Microsoft Office Online, для просмотра файла нажмите Просмотр на панели действий и выберите Просмотреть в [Office] Online (например, "Просмотреть в Word Online") или Веб-просмотр для просмотра документа в Oracle Content Management .
Если выбран файл Microsoft Office и системный администратор включил интеграцию с Microsoft Office Online, можно отредактировать файл в Office Online, нажав Редактировать и выбрав Редактировать в [Office] Online (например, "Редактировать в Word Online") или выбрав Редактировать в [Office] (рабочий стол) , чтобы отредактировать файл в клиентском приложении для настольных ПК.
Если скопировать файл в то же самое местоположение, копия переименовывается с добавлением номера к имени. Пример: Sales Report(2).doc .
Так же как при работе на локальном компьютере, удаленные файлы перемещаются в папку "Корзина" в облаке. Если вы изменили свое решение, перейдите в папку "Корзина" и восстановите удаленный объект. Чтобы проверить корзину, в меню "Документы" выберите Корзина .
Удаленные объекты находятся в корзине до тех пор, пока не наступит одно из следующих событий:
- Элемент окончательно удален.
- Квота корзины превышена.
- Автоматическая очистка корзины — выполняется по расписанию, заданному администратором сервиса, который управляет экземпляром сервиса в вашей организации.
Чтобы сделать предыдущую версию текущей, на вкладке "История версий" нажмите Сделать текущей для нужной версии.
Также можно удалить предыдущие версии или выгрузить более ранние версии, нажав Удалить или Выгрузить .
Расширение файла изменить невозможно.
Значки файлов и папок
Ваш администратор сервиса отвечает за назначение вашей квоты хранилища . Чтобы узнать, какой объем памяти для хранения файлов вам доступен, выполните следующие действия:
- В веб-браузере коснитесь значка пользователя и нажмите Параметры . В меню Параметры выберите Документы .
- На мобильном устройстве коснитесь значка Настройки , чтобы открыть информацию о настройках.
Здесь отображается максимальный объем памяти, который вам выделен, и объем, который занят файлами на данный момент. Содержимое корзины также учитывается при расчете квоты пользователя. Например, если вы храните файлы общим объемом 1 ГБ, в вашей корзине содержатся файлы общим объемом 1 ГБ и ваша общая квота составляет 5 ГБ, то у вас осталось 3 ГБ доступной памяти.
Если к папке предоставлен общий доступ и пользователи добавляют туда файлы, размер этих файлов учитывается в вашей квоте, поскольку папка принадлежит вам. Если другой пользователь предоставил вам доступ к своей папке, содержимое этой папки не влияет на вашу квоту. Если вам не хватает предоставленного объема памяти, обратитесь к администратору сервиса.
– О, никакое убежище не выдержит попадания метеорита. Но ведь у вас, как и у каждого, есть резерв, так что можете не беспокоиться.
Станислав Лем, «Звёздные дневники Ийона Тихого»
Резервным копированием называется сохранение копии данных где-то вне основного места их хранения.
Главное назначение резервного копирования – восстановление данных после их потери. В связи с этим нередко приходится слышать, что при наличии реплики базы данных с неё всегда можно восстановить данные, и резервное копирование не нужно. На самом деле резервное копирование позволяет решить как минимум три задачи, которые не могут быть решены при помощи реплики, да и реплику без резервной копии не инициализировать.
Во-первых, резервная копия позволяет восстановить данные после логической ошибки. Например, бухгалтер удалил группу проводок или администратор БД уничтожил табличное пространство. Обе операции абсолютно легитимны с точки зрения базы данных, и процесс репликации воспроизведёт их в базе-реплике.
Во-вторых, современные СУБД – весьма надёжные программные комплексы, однако изредка всё же происходит повреждение внутренних структур базы данных, после которого доступ к данным пропадает. Что особенно обидно, такое нарушение происходит обычно при высокой нагрузке или при установке какого-нибудь обновления. Но как высокая нагрузка, так и регулярные обновления говорят о том, что база данных – отнюдь не тестовая, и данные, хранящиеся в ней, ценны.
Наконец, третья задача, решение которой требует наличия резервной копии, – это клонирование базы, например, для целей тестирования.
Резервное копирование баз данных так или иначе базируется на одном из двух принципов:
- Выборка данных с последующим сохранением в произвольном формате;
- Снимок состояния файлов БД и сохранение журналов.
Требования к копированию файлов
Существуют некоторые условия, которые должны быть удовлетворены при использовании пакета DBMS_FILE_TRANSFER для копирования файлов.
- Исходные файл должны быть того же типа, что и целевые файлы. То есть файлы в двух системах должны быть либо файлами операционной системы, либо файлами ASM.
- Файлы не могут быть размером больше 2 Тбайт, и размер каждого должен быть кратен 512 байт.
- Нельзя выполнять преобразование наборов символов при копировании файлов.
- Потребуется выдать явные привилегии всем непривилегированным пользователям базы данных, прежде чем они смогут использовать файлы, переданные пакетом DBMS_FILE_TRANSFER .
«Холодное» сохранение файлов БД
Очевидная идея – остановить базу данных и скопировать все её файлы. Такая резервная копия называется «холодной». Способ крайне надёжный и простой, но у него есть два очевидных недостатка:
- из «холодной» резервной копии можно восстановить только то состояние базы данных, которое было в момент останова; транзакции, сделанные после рестарта базы, в «холодную» резервную копию не попадут;
- далеко не у каждой базы данных есть технологическое окно, когда базу можно остановить.
- «холодная» копия иногда должна включать в себя и журналы. Методы определения журналов, которые должны попасть в «холодную» копию, индивидуальны для каждой СУБД. Например, в Oracle необходимо скопировать так называемые online redo, то есть фиксированное количество журнальных файлов в специальном каталоге, причём даже тогда, когда база остановлена корректно. В PostgreSQL нужно сохранить все журналы начиная с журнала, содержащего последнюю контрольную точку, информация о которой содержится в управляющем файле.
- каталог базы данных может содержать достаточно большие файлы временных табличных пространств, которые не обязательно включать в резервную копию. Кстати, это замечание верно и для «горячего» резервного копирования.
Выгрузка данных
В наборе утилит, прилагающихся к любой СУБД, обязательно есть инструменты для выгрузки и загрузки данных. Данные сохраняются либо в текстовом формате, либо в двоичном формате, специфичном для конкретной СУБД. В таблице ниже приведён список таких инструментов:
Двоичный формат | Текстовый формат | |
---|---|---|
Oracle | DataPump Export/DataPump Import Export/Import | SQL*Plus/SQL*Loader |
PostgreSQL | pg_dump, pg_dumpall/pg_restore | pg_dump, pg_dumpall/psql |
Microsoft SQL Server | bcp | bcp |
DB2 | unload/load | unload/load |
MySQL | mysqldump, mysqlpump/mysql, mysqlimport | |
MongoDB | mongodump/mongorestore | mongoexport/mongoimport |
Cassandra | nodetool snapshot/sstableloader | cqlsh |
Текстовый формат хорош тем, что его можно редактировать или даже создавать внешними программами, а двоичный в свою очередь хорош тем, что позволяет быстрее выгружать и загружать данные за счёт распараллеливания загрузки и экономии ресурсов на преобразовании форматов.
Несмотря на простоту и очевидность идеи выгрузки данных, для резервирования нагруженных промышленных баз такой метод применяют редко. Вот причины, по которым выгрузка не подходит для полноценного резервного копирования:
- процесс выгрузки создаёт значительную нагрузку на систему-источник;
- выгрузка занимает много времени – к моменту окончания выгрузки она станет уже неактуальной;
- сделать согласованную выгрузку всей базы данных при высокой нагрузке практически невозможно, поскольку СУБД вынуждена хранить снимок своего состояния на момент начала выгрузки. Чем больше транзакций совершено с момента начала выгрузки, тем больше объём снимка (неактуальных копий данных в PostgreSQL, пространства undo в Oracle, tempdb в Microsoft SQL Server и т. п.);
- выгрузка сохраняет логическую структуру данных, но не сохраняет их физическую структуру – параметры физического хранения таблиц, индексы и др.; восстановление индексов при загрузке может занимать значительное время.
- высокая избирательность: можно выгрузить отдельные таблицы, отдельные поля и даже отдельные строки;
- выгруженные данные можно загрузить в базу данных другой версии, а если выгрузка сделана в текстовом формате, то и в другую базу данных.
Самым же распространённым методом резервного копирования баз данных является копирование файлов базы.
GET_FILE
Процедура GET_FILE используется для копирования двоичных файлов с удаленного сервера на локальный. Для начала подключитесь к удаленному серверу и создайте объект исходного каталога, как показано ниже:
Затем зайдите на локальный сервер и создайте объект целевого каталога:
Создав исходный и целевой каталоги, удостоверьтесь в наличии связи между двумя базами данных и создайте ее в случае отсутствия:
Прежде чем создавать связь между базами данных,нужно убедиться, что соединение с базой данных prod1 установлено, например, с использованием файла tnsnames.ora.Теперь можно выполнить процедуру GET_FILE для передачи файла с удаленного сервера на локальный, как показано ниже:
Обратите внимание, что в атрибуте SOURCE_DATABASE указывается имя связи с удаленной базой данных.
«Горячее» сохранение файлов
Большинство резервных копий современных баз данных выполняется путём копирования файлов базы данных без остановки базы. Здесь видны несколько проблем:
- В момент начала копирования содержимое базы данных может не совпадать с содержимым файлов, т. к. часть информации находится в кеше и ещё не записана на диск.
- Во время копирования содержимое базы может меняться. Если используются изменяемые структуры данных, то меняется содержимое файлов, а при использовании неизменяемых структур меняется набор файлов: новые файлы появляются, а старые удаляются.
- Поскольку запись данных в базу и чтение файлов БД никак не синхронизированы, программа резервного копирования может прочитать некорректную страницу, в которой половина будет от старой версии страницы, а другая половина – от новой.
- в Oracle это отдельная команда ALTER DATABASE/TABLESPACE BEGIN BACKUP;
- в PostgreSQL – функция pg_start_backup();
- в Microsoft SQL Server и DB2 подготовка к резервному копированию выполняется неявно в процессе выполнения команды BACKUP DATABASE;
- в MySQL Enterprise, Percoba Server, Cassandra и MongoDB подготовка неявно выполняется внешней утилитой – mysqlbackup, Percona XtraBackup, OpsCenter и Ops Manager соответственно.
Вот как выглядит подготовка к резервному копированию в СУБД с изменяемыми дисковыми структурами, т. е. во всех традиционных дисковых реляционных системах:
- Запоминается момент начала резервного копирования; резервная копия должна будет содержать журналы базы данных начиная с этого момента.
- Выполняется контрольная точка, то есть все изменения, которые произошли в страницах данных до запомненного момента, сбрасываются на диск. Это гарантирует, что журналы до момента начала резервного копирования при восстановлении не потребуются.
- Включается особый режим журналирования: если страница данных изменилась в первый раз после загрузки с диска, то вместо того, чтобы записывать в журнал изменения страницы, база запишет туда страницу целиком. При выполнении подготовительной процедуры все страницы вытесняются на диск, и поэтому при первом изменении блок всегда будет записан в журнал целиком. Но если в процессе резервного копирования страница снова будет вытеснена на диск, то следующее её изменение также приведёт к появлению в журнале полной копии страницы. Это гарантирует, что если вдруг при копировании файла с данными страница получится некорректной, применение журнала сделает его корректной вновь.
- Блокируется изменение заголовков файлов данных, то есть той его части, изменения которой не отражаются в журналах. Это гарантирует, что заголовок будет скопирован корректно, а потом к файлу данных корректно будут применены журналы.
По окончании резервного копирования нужно перевести базу данных обратно в обычное состояние. В Oracle это делается командой ALTER DATABASE/TABLESPACE END BACKUP, в PostgreSQL – вызовом функции pg_stop_backup(), а в других базах – внутренними подпрограммами соответствующих команд или внешних сервисов.
Вот как выглядит временнáя диаграмма процесса резервного копирования:
- Подготовка к резервному копированию (begin backup) занимает время, иногда значительное. Даже если используются зеркальные тома или файловые системы с возможностью изготовления снимков, процесс резервного копирования не будет мгновенным.
- Вместе с файлами данных необходимо сохранить журналы начиная с момента начала подготовки к резервному копированию и заканчивая моментом возврата базы в нормальное состояние.
- Восстановиться из этой резервной копии можно на момент возврата базы в нормальное состояние. Восстановление на более ранний момент невозможно.
- Данные из памяти сбрасываются на диск.
- Фиксируется список файлов, попадающих в резервную копию. До тех пор, пока процесс резервного копирования не закончится, базе запрещено удалять эти файлы, даже если они становятся не нужны.
PUT_FILE
Процедура PUT_FILE служит для передачи двоичного файла с локального сервера на удаленный. Как и в случае с предыдущими двумя процедурами, сначала необходимо создать объекты исходного и целевого каталога, как показано ниже (вдобавок следует удостовериться в существовании связи между локальной и удаленной базами данных):
После этого можно использовать процедуру PUT_FILE для помещения локального файла на удаленный сервер:
Копировать двоичные файлы можно с использованием сервера баз данных, полностью минуя операционную систему. Пакет DBMS_FILE_TRANSFER позволяет копировать двоичные файлы на одном и том же сервере или передавать их между разными базами данных Oracle.
Читайте также: