Oracle сохранить изменения в бд
Нужно ли программисту прикладных приложений понимать как работает БД? Том Кайт, признанный специалист Oracle, автор знаменитой колонки asktom, в своей книге «Oracle для профессионалов. Архитектура и основные особенности.» настаивает, что это просто необходимо. Даже если в вашей команде есть грамотный администратор, знание того, как работает СУБД Oracle поможет вам лучше понимать друг друга и эффективней взаимодействовать, не говоря уже о случае, когда такого специалиста у вас нет. В данном топике я упомяну об основных вещах, понимание которых позволит грамотно работать с БД Oracle и использовать некоторые её особенности с большой отдачей для вашего приложения. Если же вы уже прочитали вышеупомянутую книгу Тома Кайта, то можете просто исползовать эту статью в качестве памятки. Одно замечание — книжку я читал давно, и тогда еще последней версией БД Oracle была 9i, курсы по администрированию я тоже проходил по девятке, так что, если в десятке и выше что-то поменялось и добавилось, то не обессудьте. Хотя я пишу о довольно фундаментальных вещах, которые вряд ли сильно поменяись.
Что позволяет БД Oracle работать так быстро?
Когда вы меняете данные в БД, то ваши изменения сначала идут в кэш, а потом асинхронно в нескольких потоках (число можно сконфигурировать) пишутся на диск. Синхронно же пишется специальных лог (оперативный журнальный файл), чтобы была возможность восстановить данные после сбоя, если они еще не успели с кэша сброситься на диск. Данный подход позволяет выиграть в скорости, так как в этом случае на диск все пишется последовательно в один файл, причем можно настроить так, чтобы писалось параллельно на два или больше дисков, тем самым увеличивая надежность защиты от потери изменений. Описанных файлов должно быть несколько, и они используются по кругу: как только все данные защищенные одним из лог файлов были записаны фоновым процессом в блоки данных на диск, то данный лог файл может быть переиспользован. Таким образом в какой-то мере это позволяет еще и сэкономить, имея ультрабыстрые диски небольшого размера только для небольших журнальных файлов используемых по кругу.
Обычно я рассказываю об этом, когда мне предлагают что-то сохранять просто в файл на диске, так как это будет «быстрее» за счет того, что мы будет писать все данные последовательно и головке жесткого диска не надо будет бегать и искать рэндомные блоки. Я все же настаиваю, что мы тут ничего не выиграем, так как будем писать на медленный диск, который скоро всего активно используется множеством других процессов для записи огромного количества различных логов, а Oracle синхронно тоже пишет у себя на диск только последовательно, как я описал выше.
Whole Database and Partial Database Backups
This section contains the following topics:
Oracle Database Utilities for information about logical backups
Whole Database Backups
A whole database backup is a backup of every datafile in the database, plus the control file. Whole database backups are the most common type of backup.
Whole database backups can be taken in either ARCHIVELOG or NOARCHIVELOG mode. Before performing whole database backups, however, be aware of the implications of backing up in ARCHIVELOG and NOARCHIVELOG modes.
Figure 15-1 illustrates the valid configuration options given the type of backup that is performed.
Figure 15-1 Whole Database Backup Options
A whole database backup is either a consistent backup or an inconsistent backup . Whether a backup is consistent determines whether you need to apply redo logs after restoring the backup.
Tablespace Backups
A tablespace backup is a backup of the datafiles that constitute the tablespace. For example, if tablespace users contains datafiles 2 , 3 , and 4 , then a backup of tablespace users backs up these three datafiles.
Tablespace backups, whether online or offline, are valid only if the database is operating in ARCHIVELOG mode. The reason is that redo is required to make the restored tablespace consistent with the other tablespaces in the database.
Datafile Backups
A datafile backup is a backup of a single datafile. Datafile backups, which are not as common as tablespace backups, are valid in ARCHIVELOG databases. The only time a datafile backup is valid for a database in NOARCHIVELOG mode is if:
Every datafile in a tablespace is backed up. You cannot restore the database unless all datafiles are backed up.
The datafiles are read only or offline-normal.
Восстановление на точку
Резервная копия позволяет восстановить состояние базы данных на момент, когда завершилась команда возврата из режима резервного копирования. Однако авария, после которой потребуется восстановление, может произойти в любой момент. Задача восстановления состояния БД на произвольный момент называется «восстановлением на точку» (point-in-time recovery).
Чтобы обеспечить такую возможность, следует сохранять журналы БД начиная с момента окончания резервного копирования, а в процессе восстановления продолжить применять журналы к восстановленной копии. После того, как БД восстановлена из резервной копии на момент окончания копирования, состояние базы (файлов и кэшированных страниц) гарантированно корректно, поэтому особый режим журналирования не нужен. Применяя журналы до нужного момента, можно получить состояние базы данных на любую точку во времени.
Если скорость восстановления резервной копии ограничена лишь пропускной способностью диска, то скорость применения журналов обычно ограничена производительностью процессора. Если в основной базе данных изменения происходят параллельно, то при восстановлении все изменения выполняются последовательно – в порядке чтения из журнала. Таким образом время восстановления линейно зависит от того, насколько далеко точка восстановления отстоит от точки окончания резервного копирования. Из-за этого приходится довольно часто делать полные резервные копии – минимум раз в неделю для баз с небольшой транзакционной нагрузкой и до ежедневного копирования высоконагруженных баз.
Еще пара заметок для программиста
Если у вас колонка имеет тип VARCHAR2(100), то попытка туда запихнуть строку longString.substring(0, 100) не факт, что увенчается успехом, так как ограничение 100 в определении колонки по умолчанию относится к количеству байтов, а не символов, поэтому при наличии двухбайтовых символов вы можете попасть впросак. На самом деле данное поведение можно немного сконфигурировать, подробнее можно почитать тут. Хорошо если вы еще не пытаетесь выполнить вставку в бесконечном цикле, по принципу делать пока не получиться, ведь это «получиться» в данном случае никогда не наступит.
Ну и общая рекомендация для всех типов БД: никогда не делайте update всех колонок в таблице при изменении одного поля объекта. Кажется весьма очевидным, но как показывает практика, данный антипаттерн часто имеет место быть, поэтому я настоятельно рекомендую проверить, что ваши фреймворки делают UPDATE только действительно измененных полей.
«Холодное» сохранение файлов БД
Очевидная идея – остановить базу данных и скопировать все её файлы. Такая резервная копия называется «холодной». Способ крайне надёжный и простой, но у него есть два очевидных недостатка:
- из «холодной» резервной копии можно восстановить только то состояние базы данных, которое было в момент останова; транзакции, сделанные после рестарта базы, в «холодную» резервную копию не попадут;
- далеко не у каждой базы данных есть технологическое окно, когда базу можно остановить.
- «холодная» копия иногда должна включать в себя и журналы. Методы определения журналов, которые должны попасть в «холодную» копию, индивидуальны для каждой СУБД. Например, в Oracle необходимо скопировать так называемые online redo, то есть фиксированное количество журнальных файлов в специальном каталоге, причём даже тогда, когда база остановлена корректно. В PostgreSQL нужно сохранить все журналы начиная с журнала, содержащего последнюю контрольную точку, информация о которой содержится в управляющем файле.
- каталог базы данных может содержать достаточно большие файлы временных табличных пространств, которые не обязательно включать в резервную копию. Кстати, это замечание верно и для «горячего» резервного копирования.
Подвисание некоторых запросов на запись
При зависании некоторых ваших запросов в произвольный момент времени стоит заглянуть в alert.log на предмет наличия incomplete checkpoint. Это говорит о том, что ваши оперативные журнальные файлы слишком большие или их слишком мало, таким образом, защищаемые ими данные не успевают сбрасываться из кэша на диск, а СУБД заполнила уже все доступные оперативные журнальные файлы и хочет использовать их по кругу повторно, чего делать ни в коем случае нельзя, вот и появляется пауза. Хотя если ваше приложение работает на java, то в первую очередь я бы загляну на наличия Full GC в логах.
Заключение
Я попытался описать большинство вещей, который на мой взгляд могут пригодится программисту. Так как их довольно много, то я их только обозначил, часто не вдаваясь в детали. Как конкретно сделать необходимую настройку можно всегда прочитать в упомянутой книжке Тома Кайта, найти в колонке asktom или просто нагуглить. Главное знать что гуглить, и, надеюсь, данный топик вам это подсказал.
Компания Oracle рекомендует применять для резервного копирования и восстановления баз данных утилиту RMAN, поскольку она изначально учитывает особенности используемых в Oracle структур блоков и потому способна обеспечивать замечательную производительность; кроме того, она оснащена возможностями вроде сжатия, возобновления операций резервного копирования и восстановления, отслеживания изменений в блоках и интеграции с ПО уровня управления носителями (MML). Однако делать полностью действительные резервные копии вполне можно и самостоятельно, без помощи RMAN или Oracle Secure Backup, за счет применения предлагаемых в операционной системе команд копирования, наподобие cp и dd в UNIX и copy в Windows. При желании делать предназначенные для хранения на ленте резервные копии можно также подключаться к диспетчеру носителей. В случае такого подхода необходимо самостоятельно отслеживать все резервные копии, проверять их действительность, а также принимать решение о том, какие из них использовать во время сеанса восстановления. Именно поэтому Oracle и называет подобные методы создания резервных копий пользовательскими (user-managed backups).
При наличии простой базы данных Oracle и не слишком обременительных требований по резервному копированию, тратить время и силы на изучение утилиты RMAN может быть невыгодно. В таком случае пользовательские методы резервного копирования, пожалуй, являются идеальным решением, даже несмотря на утрату всех специальных возможностей, встроенных в RMAN.
Неблокирующее чтение и сегмент отката
Одной из наиболее замечательных особенностей СУБД Oracle является неблокирующее чтение, которое достигается за счет сегмента отката. Запросы к Oracle на чтение никогда не блокируются, так как данные почти всегда могут быть прочитаны из сегмента отката.
Сегмент отката дает еще одну плюшку: из него можно попытаться считать немного устаревшие данные для какой-нибудь таблицы, которые были в ней на определенный момент. Называется данная фича — flashback.
Однако иногда сегмент отката может подложить свинью: если у вас есть большой job для bulk удаления данных (удаление генерирует всех больше данных в сегменте отката), то вы можете получить ORA-01555: snapshot too old. Главное что в этом случае надо помнить — это то, что не надо переписывать ваш job, чтобы он коммитил через каждые N операций, а нужно использовать отдельный специально созданный сегмент отката для таких операций.
Introduction to Recovery
To restore a physical backup of a datafile or control file is to reconstruct it and make it available to the Oracle database server. To recover a restored datafile is to update it by applying archived redo logs and online redo logs, that is, records of changes made to the database after the backup was taken. If you use RMAN, then you can also recover datafiles with incremental backups, which are backups of a datafile that contain only blocks that changed after a previous incremental backup.
After the necessary files are restored, media recovery must be initiated by the user. Media recovery involves various operations to restore, roll forward, and roll back a backup of database files.
Media recovery applies archived redo logs and online redo logs to recover the datafiles. Whenever a change is made to a datafile, the change is first recorded in the online redo logs. Media recovery selectively applies the changes recorded in the online and archived redo logs to the restored datafile to roll it forward.
To correct problems caused by logical data corruptions or user errors, you can use Oracle Flashback. Oracle Flashback Database and Oracle Flashback Table let you quickly recover to a previous time.
Figure 15-2 illustrates the basic principle of backing up, restoring, and performing media recovery on a database.
Figure 15-2 Media Recovery
Unlike media recovery, Oracle performs crash recovery and instance recovery automatically after an instance failure. Crash and instance recovery recover a database to its transaction-consistent state just before instance failure. By definition, crash recovery is the recovery of a database in a single-instance configuration or an Oracle Real Application Clusters configuration in which all instances have crashed. In contrast, instance recovery is the recovery of one failed instance by a live instance in an Oracle Real Application Clusters configuration.
– О, никакое убежище не выдержит попадания метеорита. Но ведь у вас, как и у каждого, есть резерв, так что можете не беспокоиться.
Станислав Лем, «Звёздные дневники Ийона Тихого»
Резервным копированием называется сохранение копии данных где-то вне основного места их хранения.
Главное назначение резервного копирования – восстановление данных после их потери. В связи с этим нередко приходится слышать, что при наличии реплики базы данных с неё всегда можно восстановить данные, и резервное копирование не нужно. На самом деле резервное копирование позволяет решить как минимум три задачи, которые не могут быть решены при помощи реплики, да и реплику без резервной копии не инициализировать.
Во-первых, резервная копия позволяет восстановить данные после логической ошибки. Например, бухгалтер удалил группу проводок или администратор БД уничтожил табличное пространство. Обе операции абсолютно легитимны с точки зрения базы данных, и процесс репликации воспроизведёт их в базе-реплике.
Во-вторых, современные СУБД – весьма надёжные программные комплексы, однако изредка всё же происходит повреждение внутренних структур базы данных, после которого доступ к данным пропадает. Что особенно обидно, такое нарушение происходит обычно при высокой нагрузке или при установке какого-нибудь обновления. Но как высокая нагрузка, так и регулярные обновления говорят о том, что база данных – отнюдь не тестовая, и данные, хранящиеся в ней, ценны.
Наконец, третья задача, решение которой требует наличия резервной копии, – это клонирование базы, например, для целей тестирования.
Резервное копирование баз данных так или иначе базируется на одном из двух принципов:
- Выборка данных с последующим сохранением в произвольном формате;
- Снимок состояния файлов БД и сохранение журналов.
Частичное резервное копирование базы данных
Выполнять резервное копирование сразу всей базы данных вовсе не обязательно. Можно провести резервное копирование только какой-нибудь ее части, например, табличного пространства или вообще одного файла данных. Обычно частичное резервное копирование базы данных допускается выполнять только тогда, когда база данных функционирует в режиме ARCHIVELOG, однако существует и пара исключений из этого правила. В частности, если база данных функционирует в режиме NOARCHIVELOG и содержит какие-то доступные только для чтения или доступные обычно лишь в автономном режиме табличные пространства, разрешается выполнять резервное копирование только этих табличных пространств.
Выполнять резервное копирование табличного пространства можно как в оперативном, так и в автономном режиме, в зависимости от существующих потребностей. Для начала давайте рассмотрим пример выполнения резервного копирования табличного пространства в автономном режиме. В таком случае сначала понадобится перевести табличное пространство в автономный режим, а затем выполнить резервное копирование файлов, из которых оно состоит:
Здесь видно, что в данном примере табличному пространству USERS принадлежит только один файл данных. Следовательно, для того, чтобы выполнить резервное копирование этого табличного пространства, достаточно выполнить резервное копирование просто этого файла данных. Но сначала потребуется перевести табличное пространство в автономный режим, исключив на время резервного копирования всякую вероятность получения пользователями доступа к любому из его файлов данных:
Теперь можно спокойно использовать утилиту операционной системы наподобие cp (или copy, если дело происходит в системе Window) для выполнения резервного копирования принадлежащего табличному пространству USERS файла данных:
Закончив копировать все файлы данных, которые принадлежат табличному пространству (в данном примере имеется только один файл данных), нужно снова перевести табличное пространство в оперативный режим:
Для того чтобы выполнить резервное копирование табличного пространства без его перевода в автономный режим, сначала необходимо перевести его в режим резервного копирования, чтобы уведомить базу данных о начале процесса оперативного резервного копирования:
Далее нужно скопировать принадлежащий этому табличному пространству файл или файлы данных:
И, наконец, напоследок необходимо выполнить следующую команду, уведомив базу данных о завершении процесса оперативного резервного копирования:
Выгрузка данных
В наборе утилит, прилагающихся к любой СУБД, обязательно есть инструменты для выгрузки и загрузки данных. Данные сохраняются либо в текстовом формате, либо в двоичном формате, специфичном для конкретной СУБД. В таблице ниже приведён список таких инструментов:
Двоичный формат | Текстовый формат | |
---|---|---|
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 и т. п.);
- выгрузка сохраняет логическую структуру данных, но не сохраняет их физическую структуру – параметры физического хранения таблиц, индексы и др.; восстановление индексов при загрузке может занимать значительное время.
- высокая избирательность: можно выгрузить отдельные таблицы, отдельные поля и даже отдельные строки;
- выгруженные данные можно загрузить в базу данных другой версии, а если выгрузка сделана в текстовом формате, то и в другую базу данных.
Самым же распространённым методом резервного копирования баз данных является копирование файлов базы.
Инкрементальное резервное копирование
Чтобы ускорить восстановление на точку, хотелось бы иметь возможность выполнять резервное копирование как можно чаще, но при этом не занимать лишнего места на дисках и не нагружать базу задачами резервного копирования.
Решение задачи – инкрементальное резервное копирование, то есть копирование только тех страниц данных, которые изменились с момента предыдущего резервного копирования.
Инкрементальное резервное копирование имеет смысл только для СУБД, использующих изменяемые структуры данных.
Инкремент может отсчитываться как от полной резервной копии (кумулятивная копия), так и от любой предыдущей копии (дифференциальная копия).
К сожалению, единой терминологии не существует, и разные производители используют разные термины:
Дифференциальная | Кумулятивная | |
---|---|---|
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 умеет объединять инкрементальные копии.
В отличие от многих похожих вопросов, вопрос «какой метод резервного копирования лучше» имеет однозначный ответ – лучше всего родная для используемой СУБД утилита, обеспечивающая возможность инкрементального копирования.
Для администратора БД гораздо более важными являются вопросы выбора стратегии резервного копирования и интеграция средств резервирования баз данных в корпоративную инфраструктуру. Но эти вопросы выходят за рамки данной статьи.
Что позволяет БД Oracle работать так быстро?
Когда вы меняете данные в БД, то ваши изменения сначала идут в кэш, а потом асинхронно в нескольких потоках (число можно сконфигурировать) пишутся на диск. Синхронно же пишется специальных лог (оперативный журнальный файл), чтобы была возможность восстановить данные после сбоя, если они еще не успели с кэша сброситься на диск. Данный подход позволяет выиграть в скорости, так как в этом случае на диск все пишется последовательно в один файл, причем можно настроить так, чтобы писалось параллельно на два или больше дисков, тем самым увеличивая надежность защиты от потери изменений. Описанных файлов должно быть несколько, и они используются по кругу: как только все данные защищенные одним из лог файлов были записаны фоновым процессом в блоки данных на диск, то данный лог файл может быть переиспользован. Таким образом в какой-то мере это позволяет еще и сэкономить, имея ультрабыстрые диски небольшого размера только для небольших журнальных файлов используемых по кругу.
Обычно я рассказываю об этом, когда мне предлагают что-то сохранять просто в файл на диске, так как это будет «быстрее» за счет того, что мы будет писать все данные последовательно и головке жесткого диска не надо будет бегать и искать рэндомные блоки. Я все же настаиваю, что мы тут ничего не выиграем, так как будем писать на медленный диск, который скоро всего активно используется множеством других процессов для записи огромного количества различных логов, а Oracle синхронно тоже пишет у себя на диск только последовательно, как я описал выше.
Мониторинг выполнения пользовательских операций оперативного резервного копирования
Следить за выполнением операций оперативного резервного копирования и устранять возникающие в них неполадки помогают несколько динамических представлений производительности. Операции оперативного резервного копирования могут занимать приличное количество времени, в зависимости от размера базы данных. Иногда бывает так, что процесс резервного копирования останавливается или зависает до завершения. Поэтому администратору баз данных обязательно следует знать о тех шагах, которые необходимо выполнять в подобных случаях. В табл. 15.1 перечислены все наиболее важные представления V$, которые помогают проводить мониторинг и диагностику проблем в операциях резервного копирования.
Backup and recovery procedures protect your database against data loss and reconstruct the data, should loss occur. The reconstructing of data is achieved through media recovery, which refers to the various operations involved in restoring, rolling forward, and rolling back a backup of database files. This chapter introduces concepts fundamental to designing a backup and recovery strategy.
This chapter contains the following topics:
Связывание переменных
Наверное об этом уже наслышан каждый программист, но я все же упомяну о такой обязательной техники, как связывание переменных. Дело в том, что для каждого уникального запроса строится план разбора и кладется в кэш. Если различных запросов очень много, как, например, весьма распространенный запрос по ID, то на каждый запрос буден генериться свой план, к тому же они будут вытеснять из кэша все другие планы, что может в разы увеличить время отклика вашей базы данных.
Стоит так же заметить, что не стоит этим злоупотреблять и использовать связывание для столбцов с небольшим количеством различных значений, как-то флаг is_deleted, ведь различных запросов в этом случае будет не так много, а, возможно, для более конкретного запроса СУБД удастся построить более эффективный план.
Stand by копия
Вышеупомянутые архивные файлы можно отправлять по сети и на лету применять к копии БД. Таким образом у вас всегда под рукой будет горячая копия с минимальным запаздыванием данных. В некоторых приложениях, где нет необходимости показывать данные с точностью до последнего момента, можно настроить такую БД только на чтение и разгрузить основной экземпляр БД, причем таких экземпляров на чтение может быть несколько.
Позвольте Oracle кэшировать ваши данные эффективно
В Oracle все данные читаются-пишутся не прямо на диск, а через кэш. По умолчанию кэш основан на LRU алгоритме, так что если вы читаете какую-нибудь очень большую табличку по идентификатору в больших количествах, запрашивая в каждый раз новую строчку, то такие запросы могут вытеснять из кэша небольшую статическую табличку, которой бы самое милое дело постоянно находиться в кэше. Для таких целей при создании таблицы вы можете указать специальный вид кэша, куда будут ходить запросы к вашим таблицам. Так для первой таблицы в вышеописанном примере подойдет кэш RECYCLE, который по сути не хранит никакие данные, а сразу их выбрасывает из кэша. А для второй таблицы подойдет кэш KEEP, который позволить хранить в кэше небольшие статические таблице и запросы ко всем остальным таблицам не будут вытеснять данные статических таблиц из кэша.
Индексы
Кроме всем известных индексов в виде B-деревьев в Oracle еще есть так называемые битовые индексы, которые показывают очень высокую производительность на запросах к таблицам в которых есть колонки с очень разреженными значениями. Особенно эффективно в этом случае будут работать запросы (по сравнению с обычными индексами) в которых присутствуют сложные комбинации OR и AND к разряженным столбцам. Данный индекс храниться не в B-дереве, а в битовых картах, что и дает возможность быстрого выполнения описанных запросов. Вопрос в количестве уникальных значений в таблице при которых данный индекс еще будет более предпочтителен весьма сложен: это может быть как 10 уникальных значений, так и 10 000. Здесь надо создавать индекс на конкретной таблице и смотреть что получается. Главное не пытайтесь использовать данный индекс на таблицах с большим количеством вставок и обновлений индексируемой колонки, так как такие операции будут блокировать довольно большие участки в индексируемой таблице и ваша система может встать колом или даже поймаете deadlock.
Одна из вещей, которая меня всегда очень радовала в Oracle — это возможность создания индекса по функции. Т.е. если вам в запросах приходиться использовать какую-нибудь функцию, то вы можете построить по ней индекс и значительно ускорить операции чтения.
Еще одно интересное свойство индексов, о котором необходимо знать, это то, что в индексе не хранятся значения NULL. Таким образом если вы будете делать запросы с условием или <> по индексируемой колонке, то в ответ строчек со значением NULL в индексируемой колонке вы обратно не получите. С другой стороны данное свойство можно очень эффективно использовать дня некоторых специфичных случаев. Например, у вас есть очень большая табличка в которой хранятся ордера, которая никогда не чистится. И существует фоновый процесс, который обязан все ордера отсылать в какую-нибудь backoffice систему. Первое решение, которое напрашивается — это завести еще одну колонку с флагом is_sent, где изначально стоит 0 и при отсылке мы будем проставлять 1. Т.е. фоновый процесс при каждом запуске будет делать запрос к таблице с условием is_sent=0. Битовый индекс вы здесь использовать не можете, так как табличка очень активно пополняется. Обычный индекс на основе В-дерева будет занимать очень много места, так как нужно хранить ссылки на огромное количество строчек. Но если мы слегка поменяем нашу логику и в качестве пометки отсылки, и в колонку is_sent будем класть NULL вместо 1, то индекс у нас будет крошечный, так как в любой момент в нем будут храниться только не NULL значения, а их будет очень мало.
Introduction to Backup
A backup is a copy of data. This copy can include important parts of the database, such as the control file and datafiles. A backup is a safeguard against unexpected data loss and application errors. If you lose the original data, then you can reconstruct it by using a backup.
Backups are divided into physical backups and logical backups. Physical backups, which are the primary concern in a backup and recovery strategy, are copies of physical database files. You can make physical backups with either the Recovery Manager (RMAN) utility or operating system utilities. In contrast, logical backups contain logical data (for example, tables and stored procedures) extracted with an Oracle utility and stored in a binary file. You can use logical backups to supplement physical backups.
There are two ways to perform Oracle backup and recovery: Recovery Manager and user-managed backup and recovery.
Recovery Manager (RMAN) is an Oracle utility that can back up, restore, and recover database files. It is a feature of the Oracle database server and does not require separate installation.
You can also use operating system commands for backups and SQL*Plus for recovery. This method, also called user-managed backup and recovery, is fully supported by Oracle, although use of RMAN is highly recommended because it is more robust and greatly simplifies administration.
Whether you use RMAN or user-managed methods, you can supplement your physical backups with logical backups of schema objects made using the Export utility. The utility writes data from an Oracle database to binary operating system files. You can later use Import to restore this data into a database.
This section contains the following topics:
Резервное копирование всей закрытой базы данных
Для выполнения резервного копирования при закрытой базе данных, также называемого холодным резервным копированием (cold backup), нужно, чтобы база данных была закрыта аккуратным образом посредством обычной, немедленной или транзакционной остановки.
Подвергать резервному копированию необходимо все файлы, которые требуются для восстановления базы данных Oracle: файлы данных, файлы оперативных журналов повторного выполнения и управляющие файлы. С технической точки зрения, для восстановления базы данных требуется только один управляющий файл, но если файл init.ora или SPFILE ссылается на несколько управляющих файлов, может также потребоваться выполнять резервное копирование и всех мультиплексированных копий управляющих файлов. Сначала получается перечень файлов каждой категории, а потом производится их копирование в целевое место. Ниже в этом блоге более подробно рассказывается о том, как выполняется резервное копирование трех основных видов файлов в процессе резервного копирования всей закрытой базы данных.
RMAN and User-Managed Backups
There are two types of backups: image copies and backup sets. An image copy is an exact duplicate of a datafile, control file, or archived log. You can create image copies of physical files with operating system utilities or RMAN, and you can restore them as-is without performing additional processing by using either operating system utilities or RMAN.
Unlike operating system copies, RMAN validates the blocks in the file and records the copy in the repository.
A backup set is a backup in a proprietary format that consists of one or more physical files called backup pieces. It differs from an image copy in that it can contain more than one database file, and it can also be backed up using special processing, such as compression or incremental backup. You must use RMAN to restore a backup set.
RMAN with Online Backups
Because the database continues writing to the file during an online backup, there is the possibility of backing up inconsistent data within a block. For example, assume that either RMAN or an operating system utility reads the block while database writer is in the middle of updating the block. In this case, RMAN or the copy utility could read the old data in the top half of the block and the new data in the bottom top half of the block. The block is a fractured block, meaning that the data in this block is not consistent.
During an RMAN backup, the Oracle database server reads the datafiles, not an operating system utility. The server reads each block and determines whether the block is fractured. If the block is fractured, then Oracle re-reads the block until it gets a consistent picture of the data.
When you back up an online datafile with an operating system utility (rather than with RMAN), you must use a different method to handle fractured blocks. You must first place the files in backup mode with the ALTER TABLESPACE BEGIN BACKUP statement (to back up an individual tablespace), or the ALTER DATABASE BEGIN BACKUP statement (to back up the entire database). After an online backup is completed, you must run the ALTER TABLESPACE . END BACKUP or ALTER DATABASE END BACKUP statement to take the tablespace out of backup mode.
When updates are made to files in backup mode, additional redo data is logged. This additional data is needed to repair fractured blocks that might be backed up by the operating system utility.
Control File Backups
Backing up the control file is a crucial aspect of backup and recovery. Without a control file, you cannot mount or open the database.
You can instruct RMAN to automatically backup the control file whenever you run backup jobs. The command is CONFIGURE CONTROLFILE AUTOBACKUP . Because the autobackup uses a default filename, RMAN can restore this backup even if the RMAN repository is unavailable. Hence, this feature is extremely useful in a disaster recovery scenario.
You can make manual backups of the control file by using the following methods:
The RMAN BACKUP CURRENT CONTROLFILE command makes a binary backup of the control file, as either a backup set or an image copy.
The SQL statement ALTER DATABASE BACKUP CONTROLFILE makes a binary backup of the control file.
The SQL statement ALTER DATABASE BACKUP CONTROLFILE TO TRACE exports the control file contents to a SQL script file. You can use the script to create a new control file. Trace file backups have one major disadvantage: they contain no records of archived redo logs, and RMAN backups and copies. For this reason, binary backups are preferable.
Archived Redo Log Backups
Archived redo logs are essential for recovering an inconsistent backup. The only way to recover an inconsistent backup without archived logs is to use RMAN incremental backups. To be able to recover a backup through the most recent log, every log generated between these two points must be available. In other words, you cannot recover from log 100 to log 200 if log 173 is missing. If log 173 is missing, then you must halt recovery at log 172 and open the database with the RESETLOGS option.
Because archived redo logs are essential to recovery, you should back them up regularly. If possible, then back them up regularly to tape.
You can make backups of archived logs by using the following methods:
The RMAN BACKUP ARCHIVELOG command
The RMAN BACKUP . PLUS ARCHIVELOG command
An operating system utility
Резервное копирование всей открытой базы данных
Между резервным копированием закрытой и открытой базы данных (также называемым горячим резервным копированием) существует большая разница. Процедуры резервного копирования открытой базы данных не исключают вероятность внесения пользователями изменений в данные во время резервного копирования файлов, что требует применения более сложных механизмов на стороне сервера Oracle.
Для полного резервного копирования открытой базы данных необходимо делать резервные копии всех файлов данных, управляющих файлов и архивных журналов повторного выполнения. Для этого можно применять обычные поддерживаемые в операционной системе команды копирования, но из-за того, что база данных фактически находится в рабочем состоянии, помимо них требуется также использовать и дополнительные команды, чтобы резервные копии получались действительными и согласованными. Чтобы разобраться в этом, необходимо понять, что происходит внутри самой базы данных при ее резервном копировании в оперативном режиме.
При первоначальной подготовке табличного пространства к резервному копированию за счет выполнения команды BEGIN BACKUP, Oracle обращает внимание на SCN-номера в заголовках файлов данных и фиксирует (“замораживает”) их. Другими словами, SCN-номера контрольных точек в заголовках файлов данных будут оставаться со своими прежними значениями до самого завершения резервного копирования и выполнения команды END BACKUP. Oracle будет продолжать записывать все изменения в файлы данных и файлы журналов повторного выполнения, но файлы журналов повторного выполнения будут заполнятся довольно быстро в большинстве случаев, поскольку Oracle будет записывать весь блок данных, а не только изменения, которые были внесены в него в результате отдельных транзакций, как это делается во время обычного резервного копирования. При внесении пользователями изменений во время оперативного резервного копирования, создание контрольных точек и запись блоков данных на диск будет продолжать происходить обычным образом. По завершении резервного копирования всего табличного пространства Oracle будет увеличивать SCN-номер контрольной точки каждого файла до самого последнего фактического значения SCN.
Важный момент в процессе горячего резервного копирования состоит в том, чтобы в случае, если до завершения резервного копирования возникнет какая-нибудь авария, всегда можно было выполнить восстановление на основе контрольной точки, которая была зафиксирована при первоначальном переводе табличного пространства в режим резервного копирования. Номер SCN, который замораживается в заголовках файлов, размещается там сразу же после контрольной точки, что приводит к сбрасыванию всех измененных записей из буфера в файлы данных. Во время процедур горячего резервного копирования в журналах повторного выполнения наблюдается приличный объем активности, большая часть которой связана с обработкой проблемы так называемых раздробленных блоков (fractured block). На момент оперативного резервного копирования определенного блока Oracle, этот блок может находиться в процессе выполнения в него записи. А это значит, что данные в создаваемой для него резервной копии могут получаться несогласованными, из-за записывания одной их части до, а второй — уже после внесения изменения. Генерируемый подобным образом несогласованный блок и называется раздробленным. Oracle приходится копировать весь такой блок в файл журнала повторного выполнения для обеспечения возможности создания его согласованной версии позже в будущем, если окажется, что он действительно был разбит во время процесса горячего резервного копирования.
Ниже перечислены шаги типичного процесса горячего резервного копирования.
- Выполните следующую команду:
- Скопируйте все файлы данных, которые являются частью всех имеющихся в базе данных табличных пространств:
- После создания резервной копии всех файлов данных завершите процесс оперативного резервного копирования с помощью следующей команды:
Команда END BACKUP заставляет Oracle вывести все табличные пространства из режима резервного копирования.
На заметку! Утилита RMAN не переводит табличные пространства ни в режим начала резервного копирования (BEGIN BACKUP), ни в режим завершения резервного копирования (END BACKUP). Сеанс сервера Oracle выполняет проверку заголовков и нижних колонтитулов в блоке данных для выяснения, не был ли тот раздроблен. Если был, тогда сервер RMAN просто считывает блок данных снова, чтобы получить его в согласованном виде.
При выполнении полного оперативного резервного копирования базы данных, функционирующей в режиме ARCHIVELOG, нужно обязательно делать резервную копию ее управляющего файла посредством специальной команды BACKUP CONTROLFILE TO 'имя_файла', как показано ниже:
Во время восстановления следует обязательно использовать сделанную подобным образом резервную копию управляющего файла во избежание проблем, которые могут возникнуть при попытке использовать обычную копию этого файла, сгенерированную операционной системой.
Как не трудно было заметить, переводить отдельно каждое табличное пространства в режим горячего резервного копирования не требуется. Начиная с Oracle Database 10g, переводить сразу все файлы данных в режим оперативного резервного копирования можно единственной командой. При этом, однако, нужно обязательно проверять, что база данных функционирует в режиме архивации журналов (ARCHIVELOG), смонтирована и открыта.
Теперь вам известно, как работает механизм оперативного резервного копирования. В листинге ниже приведен пример скрипта полного оперативного резервного копирования, который будет динамически делать резервную копию на диске для всех табличных пространства в базе данных, которую позже, при желании, можно легко скопировать на ленту.
Генерируемый в буферном файле скрипт hot_backup.sh будет выглядеть следующим образом:
Как и скрипт холодного резервного копирования базы данных Oracle, скрипт горячего резервного копирования тоже может делаться частью скрипта оболочки и запускаться в заранее определенное время.
Резервное копирование файлов данных
Получить список всех файлов данных, которые имеются в базе данных, можно посредством следующего запроса:
После этого с помощью команды cp, если дело происходит в системе UNIX (или copy, если в Windows) эти файлы данных можно скопировать в любое желаемое место. Для начала их можно копировать в файл операционной системы, а позже — переносить на ленточное устройство, чтобы иметь возможность хранить их за пределами сайта (offsite). Например, в UNIX для выполнения резервного копирования файлов данных служит такая команда:
Резервное копирование файлов оперативных журналов повторного выполнения
Получать список файлов оперативных журналов повторного выполнения можно с помощью показанного ниже запроса:
Поскольку здесь подразумевается, что выполняется резервное копирование всей закрытой базы данных, резервные копии будут иметь согласованный вид, т.е. при остановке базы данных все файлы будут иметь согласованный вид, и не будут нуждаться в выполнении восстановления при запуске. Таким образом, резервные копии оперативных журналов не особо полезны при восстановлении, потому выполнять их резервное копирование не обязательно. Тем не менее, файлы журналов повторного выполнения могут потребоваться для запуска восстановленного экземпляра, а это значит, что иногда их копирование имеет смысл.
Резервное копирование управляющих файлов
Выяснить имена управляющих файлов и место их размещения можно путем выполнения запроса к представлению V$CONTROLFILE:
Таблицы бывают разные
Кроме обычных таблиц в oracle как и во многих других БД есть так называемые индекс-таблицы, когда данные таблицы непосредственно лежат в индекс-дереве первичного ключа. Таким образом достигается сразу две вещи: во первых для чтения данных по первичному ключу вы имеете на одно чтение меньше, во вторых данные в таблице получаются упорядоченными по первичному ключу, так что операция ORDER BY PK будет выполняться без дополнительной сортировки. К недостаткам можно отнести тот факт, что отличить логирование в оперативные журнальные файлы данного индекса вы уже не сможете.
Еще один замечательный тип таблиц — это кластерные таблицы, которые позволяют хранить данные из двух или более таблиц кластеризованные по одному значению ключа в одном блоке данных. Это может быть весьма эффективно если вы всегда используете какие-нибудь таблицы совместно.
На основе кластерных таблиц есть еще кластерные хэш-таблицы, в которых для доступа вместо B-дерева используется таблица на основе хеша кластерного ключа. Звучит, конечно, очень интересно, но, честно говоря, на практике никогда не сталкивался.
Резервное копирование всей базы данных Oracle
Делать резервную копию всей базы данных можно как при открытой, так и при закрытой базе данных, если используется режим ARCHIVELOG. В случае режима NOARCHIVELOG делать резервную копию можно только при закрытой базе данных.
Простой скрипт холодного резервного копирования
Скрипт для холодного резервного копирования выглядят довольно просто. Из-за того, что резервное копирование осуществляется при закрытой базе данных, весь процесс сводится к копированию всех необходимых файлов соответствующими утилитами операционной системы. В листинге ниже показан пример скрипта холодного резервного копирования.
Выполнение приведенных выше команд приведет к созданию файла cold_backup.ksh, который затем легко превратить в исполняемый скрипт и запланировать его на регулярное выполнение.
«Горячее» сохранение файлов
Большинство резервных копий современных баз данных выполняется путём копирования файлов базы данных без остановки базы. Здесь видны несколько проблем:
- В момент начала копирования содержимое базы данных может не совпадать с содержимым файлов, т. к. часть информации находится в кеше и ещё не записана на диск.
- Во время копирования содержимое базы может меняться. Если используются изменяемые структуры данных, то меняется содержимое файлов, а при использовании неизменяемых структур меняется набор файлов: новые файлы появляются, а старые удаляются.
- Поскольку запись данных в базу и чтение файлов БД никак не синхронизированы, программа резервного копирования может прочитать некорректную страницу, в которой половина будет от старой версии страницы, а другая половина – от новой.
- в 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) занимает время, иногда значительное. Даже если используются зеркальные тома или файловые системы с возможностью изготовления снимков, процесс резервного копирования не будет мгновенным.
- Вместе с файлами данных необходимо сохранить журналы начиная с момента начала подготовки к резервному копированию и заканчивая моментом возврата базы в нормальное состояние.
- Восстановиться из этой резервной копии можно на момент возврата базы в нормальное состояние. Восстановление на более ранний момент невозможно.
- Данные из памяти сбрасываются на диск.
- Фиксируется список файлов, попадающих в резервную копию. До тех пор, пока процесс резервного копирования не закончится, базе запрещено удалять эти файлы, даже если они становятся не нужны.
Пустые строки
В оракл есть одна очень интересная особенность, от которой они теперь уже никогда не смогут избавиться. Дело в том, что если вы кладете в БД пустую строку, то она сохраниться как NULL. Таким образом при последующем чтении вы никогда не получите пустой строки, а только NULL. Имейте так же в виду, что по этой же причине пустые строки не попадают в индекс, так что если вы будете делать запросы, план выполнения которых, будет использовать индекс, то ваше пустые (вернее NULL) строки вы никогда не получите, но об этом чуть позже.
Consistent and Inconsistent Backups
A consistent backup is one in which the files being backed up contain all changes up to the same system change number (SCN) . This means that the files in the backup contain all the data taken from a same point in time. Unlike an inconsistent backup, a consistent whole database backup does not require recovery after it is restored.
An inconsistent backup is a backup of one or more database files that you make while the database is open or after the database has shut down abnormally.
Overview of Consistent Backups
A consistent backup of a database or part of a database is a backup in which all read/write datafiles and control files are checkpointed with the same SCN.
The only way to make a consistent whole database backup is to shut down the database with the NORMAL , IMMEDIATE , or TRANSACTIONAL options and make the backup while the database is closed. If a database is not shut down cleanly, for example, an instance fails or you issue a SHUTDOWN ABORT statement, then the database's datafiles are always inconsistent—unless the database is a read-only database .
Oracle makes the control files and datafiles consistent to the same SCN during a database checkpoint . The only tablespaces in a consistent backup that are allowed to have older SCNs are read-only and offline normal tablespaces, which are still consistent with the other datafiles in the backup because no changes have been made to them.
The important point is that you can open the database after restoring a consistent whole database backup without needing recovery because the data is already consistent: no action is required to make the data in the restored datafiles correct. Hence, you can restore a year-old consistent backup of your database without performing media recovery and without Oracle performing instance recovery. Of course, when you restore a consistent whole database backup without applying redo, you lose all transactions that were made since the backup was taken.
A consistent whole database backup is the only valid backup option for databases operating in NOARCHIVELOG mode, because otherwise recovery is necessary for consistency. In NOARCHIVELOG mode, Oracle does not archive the redo logs, and so the required redo logs might not exist on disk. A consistent whole backup is also a valid backup option for databases operating in ARCHIVELOG mode. When this type of backup is restored and archived logs are available, you have the option of either opening the database immediately and losing transactions that were made since the backup was taken, or applying the archived logs to recover those transactions.
Overview of Inconsistent Backups
An inconsistent backup is a backup in which the files being backed up do not contain all the changes made at all the SCNs. In other words, some changes are missing. This means that the files in the backup contain data taken from different points in time. This can occur because the datafiles are being modified as backups are being taken. Oracle recovery makes inconsistent backups consistent by reading all archived and online redo logs, starting with the earliest SCN in any of the datafile headers, and applying the changes from the logs back into the datafiles.
If the database must be up and running 24 hours a day, seven days a week, then you have no choice but to perform inconsistent backups of the whole database. A backup of online datafiles is called an online backup . This requires that you run your database in ARCHIVELOG mode.
If you run the database in ARCHIVELOG mode, then you do not have to back up the whole database at one time. For example, if your database contains seven tablespaces, and if you back up the control file as well as a different tablespace each night, then in a week you will back up all tablespaces in the database as well as the control file. You can consider this staggered backup as a whole database backup. However, if such a staggered backup must be restored, then you need to recover using all archived redo logs that were created since the earliest backup was taken.
Oracle strongly recommends that you do not make inconsistent, closed database backups in NOARCHIVELOG mode. If such a backup is used to restore the database, then data corruption might result.
Archiving Unarchived Redo Log Files
After an online backup or inconsistent closed backup, always ensure that you have the redo necessary to recover the backup by archiving the unarchived redo logs.
Backing Up the Archived Logs and the Control File
After open or inconsistent closed backups, Oracle recommends backing up all archived logs produced during the backup, and then backing up the control file after the backup completes. If you do not have all archived redo logs produced during the backup, then you cannot recover the backup because you do not have all the redo records necessary to make it consistent.
Уровни изоляции транзакций
В Oracle вообще нет уровня изоляции READ_UNCOMMITED. Дело в том, что в других базах данных он используется для достижения максимального параллелизма путем удаления блокировок чтения. Но в Oracle чтение и так всегда выполняется без блокировок, таким образом мы уже имеем все преимущества, которые может дать этот уровень, не вводя никаких дополнительных ограничений.
Вообще, в Oracle явно доступно всего два уровня изоляции: по умолчанию используется READ_COMMITTED, но при желании вы можете установить SERIALIZABLE.
Однако на уровне операторов (SELECT, UPDATE и т.д.) у вас по умолчанию уже есть REPEATABLE_READ, т.е. в рамках одного оператора вы всегда получаете согласованное чтение, что достигается конечно же за счет сегмента отката. Мне всегда очень нравился пример приводимый Томом Кайтом для описания того, что это дает. Допустим у вас есть очень большая таблица со счетами и вы выполняете SELECT на получение суммы. В Oracle, в отличие от многих других БД, даже если в середине вашего запроса другая транзакция переведет некоторую суммы с первого счета на последний, вы в итоге все равно получите данные актуальные на начало вашего запроса, так как дойдя до последний строчки ваш SELECT увидит, что строчка была изменена, пойдет в сегмент отката и прочитает данные, которые были в этой ячейке на момент начала выполнения запроса. Во многих других базах данных, вы получите ответ в виде суммы, никогда не существующей в вашей таблице. Однако в Oracle в данном случае есть опасность получить ORA-01555: snapshot too old.
В дополнение к стандартным уровням изоляции в Oracle еще есть так называемые READ_ONLY транзакции, которые дают REPEATABLE_READ в рамках всей транзакции, а не только в рамках одного оператора. Но как следует из названия, в такой транзакции вы можете выполнять только чтение.
Механизм восстановления данных
В СУБД Oracle можно включить архивацию вышеописанных оперативных журнальных файлов, и все изменения будут архивироваться. Таким образом при потере любого диска с блоками данных мы можем восстановить их на любой момент времени, включая момент прямо перед падением, накатив на последние архивные журнальные файлы текущий оперативный журнал.
Читайте также: