Для журналов транзакций также должны делаться резервные копии, причем, чаще, чем для БД. Это объясняется двумя причинами. Во-первых, копирование дает нам гарантии сохранения журналов в случае порчи носителей, на котором хранятся рабочие экземпляры журналов. Во-вторых, во всех СУБД объем журнала ограничен. Переполнение журнала приведет либо к отказу в работе СУБД, либо к потере записей о транзакциях (начиная с самых давних). После копирования журнал может очищаться и заполняться с начала. Восстановление с прокруткой вперед может потребовать использования нескольких копий журнала.
Промышленные СУБД обеспечивают создание резервных копий БД и журналов без остановки работы пользователей. Копирование также выполняется как транзакция, и в содержимом копии не отражаются изменения в БД, сделанные теми транзакциями, которые не завершились до начала копирования. Выполнение копирования может повлиять на скорость работы параллельно выполняемых приложений, но не на их работоспособность в принципе. В распоряжении администратора обычно есть средства "тонкой" настройки процессов копирования/восстановления, позволяющие найти компромисс между объемом выделяемых этим процессам ресурсов и скоростью их выполнения.
Копирование и восстановление - процессы весьма ресурсоемкие как в отношении времени и рабочей памяти, так и в отношении объема внешней памяти, необходимой для хранения копий. Поэтому администратору для каждой конкретной БД приходится разрабатывать процедуру копирования (как часто копировать, что копировать, параметры копирования, порядок хранения резервных копий и т.д.), выбирая компромиссные решения между надежностью эксплуатации БД и затратами на обеспечение этой надежности. В некоторых СУБД существует возможность копирования не всей БД, а отдельных логических единиц ее памяти. Это дает возможность копировать разные табличные пространства с разной частотой и тем снизить затраты на обеспечение гарантированной целостности БД.
5. Экспорт и импорт данных
При эксплуатации БД может возникнуть необходимость экспорта данных - представления таблиц БД в виде отдельных файлов, которые могут храниться, копироваться, пересылаться средствами ФС и обрабатываться независимыми приложениями без использования средств СУБД. Обратная задача - импорт - перенесение данных из внешних файлов в таблицы БД. Операции экспорта и импорта обеспечивают обмен данными между:
· таблицами одной и той же БД;
· разными БД в одной и той же инсталляции СУБД;
· разными инсталляциями одной СУБД на одной или разных платформах;
· СУБД и независимыми от нее приложениями, причем, такими приложениями могут быть и другие СУБД.
В некоторых случаях операции экспорта-импорта могут использоваться для оптимизации таблиц БД (утилизации неиспользуемой памяти и реорганизации индексов). Операции экспорта-импорта могут занимать больше или меньше времени в зависимости от объема данных и параметров операций, но в любом случае каждая такая операция должна выполняться как одна транзакция. Операции экспорта-импорта обеспечиваются утилитами в составе СУБД, которые вызываются специальными командами или функциями API.
5.1. Экспорт данных и форматы внешних файлов
В отличие от резервного копирования при экспорте выводится не вся БД, включая ее инфраструктуру, а только данные. Поэтому единичным объектом экспорта является таблица или виртуальная таблица. При вызове утилиты экспорта задается имя таблицы и имя файла, в который таблица экспортируется.
Поскольку в каждой конкретной задаче, для которой выполняется экспорт, может потребоваться не все содержимое таблицы, а только какое-то подмножество ее строк и столбцов, утилита экспорта обычно имеет параметры, позволяющие описать экспортируемое подмножество. Наиболее удобной формой для такого описания, конечно, является выражение SELECT.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.