Archivelog oracle что это
12.3 Controlling Archiving
You can set the archiving mode for your database and adjust the number of archiver processes.
Your Oracle operating system specific documentation for additional information on controlling archiving modes
Бэкап Файлов Параметров Сервера и Архивных Журналов Транзакций с помощью RMAN
12.3.4 Adjusting the Number of Archiver Processes
The LOG_ARCHIVE_MAX_PROCESSES initialization parameter specifies the number of ARC n processes that the database initially starts. The default is four processes.
To avoid any run-time overhead of starting additional ARC n processes:
Set the LOG_ARCHIVE_MAX_PROCESSES initialization parameter to specify that up to 30 ARC n processes be started at instance startup.
The LOG_ARCHIVE_MAX_PROCESSES parameter is dynamic, so you can change it using the ALTER SYSTEM statement.
The following statement configures the database to start six ARC n processes upon startup:
The statement also has an immediate effect on the currently running instance. It increases or decreases the current number of running ARC n processes to six.
12.2.1 Running a Database in NOARCHIVELOG Mode
When you run your database in NOARCHIVELOG mode, you disable the archiving of the redo log.
The database control file indicates that filled groups are not required to be archived. Therefore, when a filled group becomes inactive after a log switch, the group is available for reuse by LGWR.
NOARCHIVELOG mode protects a database from instance failure but not from media failure. Only the most recent changes made to the database, which are stored in the online redo log groups, are available for instance recovery. If a media failure occurs while the database is in NOARCHIVELOG mode, you can only restore the database to the point of the most recent full database backup. You cannot recover transactions subsequent to that backup.
In NOARCHIVELOG mode you cannot perform online tablespace backups, nor can you use online tablespace backups taken earlier while the database was in ARCHIVELOG mode. To restore a database operating in NOARCHIVELOG mode, you can use only whole database backups taken while the database is closed. Therefore, if you decide to operate a database in NOARCHIVELOG mode, take whole database backups at regular, frequent intervals.
Решение об Использовании Мгновенной Области Восстановления (FRA)
Рекомендуется извлечь максимальное преимущество из мгновенной области восстановления и хранить в ней как можно большее число бэкапов и файлов связанных с восстановлением, включая дисковые бэкапы, а также архивные журналы изменений.
Некоторые возможности бэкапа и восстановления БД Oracle, такие как Ретроспективная База Данных Oracle и гарантированные точки реставрации, требуют использования FRA в обязательном порядке. Однако, использование мгновенной области восстановления для этих возможностей не заставляет Вас применять ее для хранения всех файлов, связанных с восстановлением.
Однако, даже когда ее использование не обязательно, мгновенная область восстановления предлагает ряд преимуществ по сравнению с другими способами хранения бэкапов на диске. Бэкапы, перемещаемые из FRA на ленту остаются также и на диске до тех пор, пока хватает места для других требуемых файлов, уменьшая необходимость реставрации бэкапов с ленты. В то же время, устаревшие файлы, которые более не нужны для целей восстановления, а также файлы, резервно скопированные на ленту, становятся разрешенными к удалению и удаляются, когда потребуется место. Администратор (DBA) больше не должен вручную удалять старые бэкапы, и, таким образом, уменьшается вероятность того, что DBA случайно удалит файлы избыточного набора.
В будущих статьях, посвященных бэкапу и восстановлению Oracle, я подробнее расскажу об использовании и преимуществах мгновенной области восстановления.
Защита Вашего Избыточного Набора
Набор файлов, неоходимый для восстановления любого из файлов БД Oracle после сбоя – файла данных, контрольного файла или онлайн журнала изменений—называется избыточным набором (англ. redundancy set). Избыточный набор должен содержать:
- Последний бэкап контрольного файла и всех файлов данных
- Все архивные журналы изменений, сгенерированные после того, как был взят этот последний бэкап данных
- Дубликаты текущего контрольного файла и файлы онлайн журналов изменений, сгенерированные посредством мультиплексирования БД Oracle, зеркалирования ОС или того и другого
- Копии файлов конфигурации, таких как файл параметров сервера (англ. server parameter file или сокр. spfile), tnsnames.ora и listener.ora
Таким образом, минимальная база данных промышленного уровня требует по крайней мере два дисковых накопителя: один будет содержать файлы избыточного набора, а другой файлы БД. В идеале, отделите избыточный набор от основных файлов всеми возможными путями: разными томами, отдельными файловыми системами и отдельными устройствами RAID.
Простейший способ управления вашим избыточным набором – использование мгновенной области восстановления (FRA), на отдельном устройстве от рабочего набора файлов. Однако, вне зависимости от того, используете Вы FRA или нет, Oracle приводит следующие рекомендации:
- Мультиплексируйте файлы онлайн журнала транзакций (redo) и текущий контрольный файл на уровне базы данных. (Например, сконфигурируйте базу данных писать ее онлайн журналы в два или более местоположений, так, чтобы каждая операция записи выполнялась базой, а не на уровне ОС или избыточности на уровне оборудования.) Если Вы настроите мультиплексирование на уровне базы данных, то сбой ввода/вывода или сбой операции записи повредят только одну из копий.
- В идеале, мультиплексированные файлы должны распологаться на разных дисках под управлением разных контроллеров дисков. Мгновенная область восстановления является отличным местом для одной из копий этих файлов.
- Вы также можете зеркалировать онлайн журналы изменений и текущий контрольный файл на уровне ОС или на уровне оборудования, но это не замена для мультиплексирования на уровне БД.
- При работе в режиме ARCHIVELOG архивируйте журналы транзакций в несколько местоположений, в идеале на разные диски. Если Вы используете мгновенную область восстановления, то одним из этих местоположений сделайте FRA.
- Используйте зеркалирование контрольного файла посредством ОС или оборудования. Все копии контрольного файла, мультиплексированные на уровне БД, должны быть все время доступны, иначе произойдет сбой экземпляра. Если Вы используете зеркалирование контрольного файла средствами ОС или оборудования, ваша база данных может продолжать работать даже в случае, если одна из копий контрольного файла, зеркалированного на уровне ОС, не доступна из-за выхода из строя диска.
- Используйте зеркалирование средствами ОС или оборудования для основных файлов данных, если это возможно, чтобы избежать выполнения восстановления носителя для простых случаев дисковых сбоев.
- Храните по крайне мере одну копию полного избыточного набора—включая самый последний бэкап базы—на диске. Мгновенная область восстановления является идеальным местом для избыточного набора.
- Если целевая база данных хранится на RAID устройстве, то следует хранить избыточный набор на группе дисков, которые не входят в то же самое RAID устройство.
- Если Вы храните избыточный набор на ленте, то поддерживайте по крайней мере две копии данных, чтобы защититься от риска сбоя ленты. Кроме того, если у Вас есть более одного бэкапа одних и тех же данных, то рассмотрите возможность сохранения бэкапов данных в различные моменты времени. Таким образом, если один из бэкапов или разделенное зеркало было создано, когда БД уже повреждена, то у Вас по-прежнему будет бэкап, взятый, когда база данных еще была целой.
12.3.3 Performing Manual Archiving
For convenience and efficiency, automatic archiving is usually best. However, you can configure your database for manual archiving only.
When you operate your database in manual ARCHIVELOG mode, you must archive inactive groups of filled redo log files or your database operation can be temporarily suspended.
To operate your database in manual archiving mode:
Follow the procedure described in "Changing the Database Archiving Mode " , but replace the ALTER DATABASE statement with the following statement:
Connect to the database as a user with administrator privileges.
Ensure that the database is either mounted or open.
Use the ALTER SYSTEM statement with the ARCHIVE LOG clause to manually archive filled redo log files. For example, the following statement archives all unarchived redo log files:
When you use manual archiving mode, you cannot specify any standby databases in the archiving destinations.
Even when automatic archiving is enabled, you can use manual archiving for such actions as rearchiving an inactive group of filled redo log members to another location. In this case, it is possible for the instance to reuse the redo log group before you have finished manually archiving, and thereby overwrite the files. If this happens, the database writes an error message to the alert log.
Related Topics
Бэкап Файлов Параметров Сервера посредством RMAN
Как объяснено в одном из предыдущих постов, посвященных Бэкапам Контрольных файлов в RMAN, диспетчер восстановления автоматически резервирует текущий файл параметров сервера в определенных случаях. Команда BACKUP SPFILE резервирует файл параметров явно. Например:
SPFILE, который резервируется, является файлом параметров сервера, который используется в настоящее время экземпляром. Если экземпляр запускается с клиентского файла параметров инициализации, то RMAN ничего не резервирует при использовании этой команды.
12.1 What Is the Archived Redo Log?
Oracle Database lets you save filled groups of redo log files to one or more offline destinations, known collectively as the archived redo log .
The process of turning redo log files into archived redo log files is called archiving . This process is only possible if the database is running in ARCHIVELOG mode . You can choose automatic or manual archiving.
An archived redo log file is a copy of one of the filled members of a redo log group. It includes the redo entries and the unique log sequence number of the identical member of the redo log group. For example, if you are multiplexing your redo log, and if group 1 contains identical member files a_log1 and b_log1 , then the archiver process (ARC n ) will archive one of these member files. Should a_log1 become corrupted, then ARC n can still archive the identical b_log1 . The archived redo log contains a copy of every group created since you enabled archiving.
When the database is running in ARCHIVELOG mode, the log writer process (LGWR) cannot reuse and hence overwrite a redo log group until it has been archived. The background process ARC n automates archiving operations when automatic archiving is enabled. The database starts multiple archiver processes as needed to ensure that the archiving of filled redo logs does not fall behind.
You can use archived redo log files to:
Recover a database
Update a standby database
Get information about the history of a database using the LogMiner utility
The following sources document the uses for archived redo log files:
Oracle Data Guard Concepts and Administration discusses setting up and maintaining a standby database
Oracle Database Utilities contains instructions for using the LogMiner PL/SQL package
Setting the Archive Location to a User-Defined Disk Location (non-FRA)
If you’re using an init.ora file, modify the file with an OS utility (such as vi ). In this example the archive redo log location is set to /u01/oraarch/O12C :
In the prior line of code, my standard for naming archive redo log files includes the ORACLE_SID (in this example, O12C to start the string); the mandatory parameters %t , %s , and %r ; and the string .arc , to end. I like to embed the name of the ORACLE_SID in the string to avoid confusion when multiple databases are housed on one server. I like to use the extension .arc to differentiate the files from other types of database files.
Tip If you don’t specify a value for LOG_ARCHIVE_FORMAT , Oracle uses a default, such as %t_%s_%r.dbf . One aspect of the default format that I don’t like is that it ends with the extension .dbf , which is widely used for data files. This can cause confusion about whether a particular file can be safely removed because it’s an old archive redo log file or shouldn’t be touched because it’s a live data file. Most DBAs are reluctant to issue commands such as rm *.dbf for fear of accidentally removing live data files.
If you’re using an spfile , use ALTER SYSTEM to modify the appropriate initialization variables:
You can dynamically change the LOG_ARCHIVE_DEST_n parameters while your Oracle database 12C is open. However, you have to stop and start your database for the LOG_ARCHIVE_FORMAT parameter to take effect.
RECOVERING FROM SETTING A BAD SPFILE PARAMETER
Take care not to set the LOG_ARCHIVE_FORMAT to an invalid value; for example,
SQL> alter system set log_archive_format='%r_%y_%dk.arc' scope=spfile;
If you do so, when you attempt to stop and start your database, you won’t even get to the nomount phase (because the spfile contains an invalid parameter):
In this situation, if you’re using an spfile , you can’t start your instance. The easiest thing to do at this point is to create a text based init.ora file from the contents of the spfile . You can use the Linux/Unix strings command to accomplish this:
The prior command will extract the text out of the binary spfile and display it on your screen. You can then cut and paste that text into an init.ora file and use that to start your Oracle database 12C. If you’re using Windows, you can use a utility such as write.exe to display the text in a binary file.
When you specify LOG_ARCHIVE_FORMAT , you must include %t (or %T ), %s (or %S ), and d% in the format string. Table 1 lists the valid variables you can use with the LOG_ARCHIVE_FORMAT initialization parameter.
12.2 Choosing Between NOARCHIVELOG and ARCHIVELOG Mode
You must choose between running your database in NOARCHIVELOG or ARCHIVELOG mode.
The choice of whether to enable the archiving of filled groups of redo log files depends on the availability and reliability requirements of the application running on the database. If you cannot afford to lose any data in your database in the event of a disk failure, use ARCHIVELOG mode. The archiving of filled redo log files can require you to perform extra administrative operations.
Решение об Использовании Ретроспективных Возможностей Оракл и Точек Реставрации
Использование ретроспективных возможностей Oracle улучшает доступность вашей бд при исправлении воздействий нежелательных изменений в базе. Ретроспективные возможности логического уровня позволяют нетронутым объектам оставаться доступными, а Ретроспективная База Данных допускает более быструю “перемотку назад” целой базы, чем восстановление на момент времени.
Если Вы собираетесь извлечь пользу от ретроспективных возможностей Оракл логического уровня, то Вам следует принять во внимание, как база данных управляет данными отката, о чем я планирую рассказать подробнее в обозримом будущем.
You manage the archived redo log files by completing tasks such as choosing between NOARCHIVELOG or ARCHIVELOG mode and specifying archive destinations.
Using Oracle Managed Files for information about creating an archived redo log that is both created and managed by the Oracle Database server
Oracle Real Application Clusters Administration and Deployment Guide for information specific to archiving in the Oracle Real Application Clusters environment
12.3.1 Setting the Initial Database Archiving Mode
You set the initial archiving mode as part of database creation in the CREATE DATABASE statement.
Usually, you can use the default of NOARCHIVELOG mode at database creation because there is no need to archive the redo information generated by that process. After creating the database, decide whether to change the initial archiving mode.
If you specify ARCHIVELOG mode, you must have initialization parameters set that specify the destinations for the archived redo log files (see "Setting Initialization Parameters for Archive Destinations" ).
12.4.1 Setting Initialization Parameters for Archive Destinations
You can choose to archive redo logs to a single destination or to multiple destinations.
Destinations can be local—within the local file system or an Oracle Automatic Storage Management (Oracle ASM) disk group—or remote (on a standby database). When you archive to multiple destinations, a copy of each filled redo log file is written to each destination. These redundant copies help ensure that archived logs are always available in the event of a failure at one of the destinations.
To archive to only a single destination:
Specify that destination using the LOG_ARCHIVE_DEST initialization parameter.
To archive to multiple destinations:
Choose to archive to two or more locations using the LOG_ARCHIVE_DEST_ n initialization parameters, or to archive only to a primary and secondary destination using the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters.
For local destinations, in addition to the local file system or an Oracle ASM disk group, you can archive to the Fast Recovery Area. The database uses the Fast Recovery Area to store and automatically manage disk space for a variety of files related to backup and recovery. See Oracle Database Backup and Recovery User's Guide for details about the Fast Recovery Area.
Typically, you determine archive log destinations during database planning, and you set the initialization parameters for archive destinations during database installation. However, you can use the ALTER SYSTEM command to dynamically add or change archive destinations after your database is running. Any destination changes that you make take effect at the next log switch (automatic or manual).
The following table summarizes the archive destination alternatives, which are further described in the sections that follow.
n is an integer from 1 to 31. Archive destinations 1 to 10 are available for local or remote locations. Archive destinations 11 to 31 are available for remote locations only.
В режиме ARCHIVELOG восстановление возможно до момента последней зафиксированной транзакции. Большинством производственных баз данных управляют в режиме ARCHIVELOG.
Когда делаются модификации с данными в базе данных, данные о транзакциях записываются в онлайновый файл журнала транзакций. Данный файл определяется как записываемый в данный момент. Когда он заполняется, процесс Архиватора (ARCn) копирует онлайновый файл журнала в другое расположение, которое служит архивом этого файла и может храниться столько, сколько потребуется. Это обеспечивает больше возможностей для восстановления, потому что можно сохранять, резервировать и извлекать из резервных копий все архивные журналы транзакций, когда-либо сгенерированные.
Поскольку онлайновые файлы журнала транзакций используются повторно круговым способом, существует протокол, управляющий тем, когда разрешено повторно использовать очередной файл оперативного журнала. В режиме ARCHIVELOG база данных начинает писать в онлайновый файл журнала транзакций только после того, как он был заархивирован. Это гарантирует, что у каждого файла журнала транзакций есть возможность быть заархивированным.
Конфигурирование Режима ARCHIVELOG
Чтобы поместить базу данных в режим ARCHIVELOG , выполните следующие шаги:
Используя Enterprise Manager
Установите флажок “ARCHIVELOG Mode”.
Щелкните Apply. База данных может быть переведена в режим ARCHIVELOG только из состояния MOUNT .
Щелкните Yes, когда возникнет вопрос, хотите ли Вы перезапустить базу данных.
Используя команды SQL
Смонтируйте базу данных.
Введите команду ALTER DATABASE ARCHIVELOG .
Откройте базу данных.
Перевод базы данных в режим ARCHIVELOG препятствует перезаписи журналов транзакций, пока они не будут заархивированы.
Чтобы перевести базу в этот режим в Enterprise Manager, перейдите к Availability > Recovery Settings и установите флажок режима ARCHIVELOG. База данных должна быть перезапущена после этого изменения.
Чтобы выполнить команду SQL для перевода базы данных в режим ARCHIVELOG, база данных должна быть в режиме MOUNT. Если база данных в настоящий момент открыта, следует чисто завершить ее работу (без опции ABORT), а затем смонтировать ее. Далее показаны команды, позволяющие завершить работу открытой базы данных, поместить ее в режим ARCHIVELOG, и затем открыть ее:
SQL> SHUTDOWN IMMEDIATE SQL> STARTUP MOUNT SQL> ALTER DATABASE ARCHIVELOG; SQL> ALTER DATABASE OPEN; |
С базой данных в режиме NOARCHIVELOG (значение по умолчанию), восстановление возможно только до времени последнего резервного копирования. Теряются все транзакции, сделанные после этого резервного копирования.
В режиме ARCHIVELOG восстановление возможно до момента последней зафиксированной транзакции. Большинством производственных баз данных управляют в режиме ARCHIVELOG.
Отметьте: Сделайте резервную копию своей базы данных после переключения в режим ARCHIVELOG, потому что Ваша база данных восстанавливаема только из первой резервной копии, взятой в этом режиме.
12.4 Specifying Archive Destinations
Before you can archive redo logs, you must determine the destination to which you will archive, and familiarize yourself with the various destination states.
The dynamic performance (V$) views, listed in "Viewing Information About the Archived Redo Log" , provide all needed archive information.
Making Architectural Decisions
When you implement archivelog mode, you also need a strategy for managing the archived log files. The archive redo logs consume disk space. If left unattended, these files will eventually use up all the space allocated for them. If this happens, the archiver can’t write a new archive redo log file to disk, and your Oracle database 12C will stop processing transactions. At that point, you have a hung database. You then need to intervene manually by creating space for the archiver to resume work. For these reasons, there are several architectural decisions you must carefully consider before you enable archiving:
- Where to place the archive redo logs and whether to use the FRA to store them
- How to name the archive redo logs
- How much space to allocate to the archive redo log location
- How often to back up the archive redo logs
- When it’s okay to permanently remove archive redo logs from disk
- How to remove archive redo logs (e.g., have RMAN remove the logs, based on a retention policy)
- Whether multiple archive redo log locations should be enabled
- (When to schedule the small amount of downtime that’s required (if a production database)
As a general rule of thumb, you should have enough space in your primary archive redo location to hold at least a day’s worth of archive redo logs. This lets you back them up on a daily basis and then remove them from disk after they’ve been backed up.
If you decide to use a FRA for your archive redo log location, you must ensure that it contains sufficient space to hold the number of archive redo logs generated between backups. Keep in mind that the FRA typically contains other types of files, such as RMAN backup files, flashback logs, and so on. If you use a FRA, be aware that the generation of other types of files can potentially impact the space required by the archive redo log files.
You need a strategy for automating the backup and removal of archive redo log files. For user-managed backups, this can be implemented with a shell script that periodically copies the archive redo logs to a backup location and then removes them from the primary location. As you will see in later in my blog, RMAN automates the backup and removal of archive redo log files.
If your business requirements are such that you must have a certain degree of high availability and redundancy, then you should consider writing your archive redo logs to more than one location. Some shops set up jobs to copy the archive redo logs periodically to a different location on disk or even to a different server.
12.2.2 Running a Database in ARCHIVELOG Mode
When you run a database in ARCHIVELOG mode, you enable the archiving of the redo log.
The database control file indicates that a group of filled redo log files cannot be reused by LGWR until the group is archived. A filled group becomes available for archiving immediately after a redo log switch occurs.
The archiving of filled groups has these advantages:
A database backup, together with online and archived redo log files, guarantees that you can recover all committed transactions in the event of an operating system or disk failure.
If you keep archived logs available, you can use a backup taken while the database is open and in normal system use.
You can keep a standby database current with its original database by continuously applying the original archived redo log files to the standby.
You can configure an instance to archive filled redo log files automatically, or you can archive manually. For convenience and efficiency, automatic archiving is usually best. Figure 12-1 illustrates how the archiver process (ARC0 in this illustration) writes filled redo log files to the database archived redo log.
If all databases in a distributed database operate in ARCHIVELOG mode, you can perform coordinated distributed database recovery. However, if any database in a distributed database is in NOARCHIVELOG mode, recovery of a global distributed database (to make all databases consistent) is limited by the last full backup of any database operating in NOARCHIVELOG mode.
Figure 12-1 Redo Log File Use in ARCHIVELOG Mode
It is good practice to move archived redo log files and corresponding database backups from the local disk to permanent offline storage media such as tape. A primary value of archived logs is database recovery, so you want to ensure that these logs are safe should disaster strike your primary database.
12.3.2 Changing the Database Archiving Mode
To change the archiving mode of the database, use the ALTER DATABASE statement with the ARCHIVELOG or NOARCHIVELOG clause.
To change the archiving mode, you must be connected to the database with administrator privileges ( AS SYSDBA ).
The following steps switch the database archiving mode from NOARCHIVELOG to ARCHIVELOG :
An open database must first be closed and any associated instances shut down before you can switch the database archiving mode. You cannot change the mode from ARCHIVELOG to NOARCHIVELOG if any data files need media recovery.
Before making any major change to a database, always back up the database to protect against any problems. This will be your final backup of the database in NOARCHIVELOG mode and can be used if something goes wrong during the change to ARCHIVELOG mode. See Oracle Database Backup and Recovery User's Guide for information about taking database backups.
To enable or disable archiving, the database must be mounted but not open.
Changing the database archiving mode updates the control file. After changing the database archiving mode, you must back up all of your database files and control file. Any previous backup is no longer usable because it was taken in NOARCHIVELOG mode.
Oracle Real Application Clusters Administration and Deployment Guide for more information about switching the archiving mode when using Real Application Clusters
Setting the Archive Redo File Location
Before you set your database mode to archiving, you should specifically instruct Oracle where you want the archive redo logs to be placed. You can set the archive redo log file destination with the following techniques:
- Set the LOG_ARCHIVE_DEST_N database initialization parameter.
- Implement a FRA.
These two approaches are discussed in detail in the following sections.
Tip If you don’t specifically set the archive redo log location via an initialization parameter or by enabling the FRA, then the archive redo logs are written to a default location. For Linux/Unix the default location is ORACLE_HOME/dbs . For Windows the default location is ORACLE_HOME\database . For active production database systems, the default archive redo log location is rarely appropriate.
Выбор Между Режимами ARCHIVELOG и NOARCHIVELOG
Журналы транзакций вашей БД обеспечивают полную запись изменений в файлах данных вашей БД (с несколькими исключениями, такими как загрузки по прямому маршруту).
Ваша база данных может работать в двух режимах: режим ARCHIVELOG или режим NOARCHIVELOG. В режиме ARCHIVELOG используемая группа онлайн журналов изменений должна быть скопирована в одно или более архивных местоположений, прежде чем она может быть повторно использована. Архивирование журнала изменений сохраняет все транзакции, хранимые в этом журнале, так что они могут использоваться в операциях восстановления позже. В режиме NOARCHIVELOG группы онлайн журналов изменений просто перезаписываются, когда журнал заполняется и начинает использоваться повторно. Вся информация о транзакциях, записанных в этой группе онлайн журналов транзакций теряется.
Последствия Работы в Режиме NOARCHIVELOG
Работа вашей базы данных в режиме NOARCHIVELOG накладывает серьезные ограничения на вашу стратегию бэкапа и восстановления.
- Вы не можете выполнять бэкапы базы в режиме онлайн. Вы должны аккуратно остановить базу данных, прежде чем сможете взять бэкап в режиме NOARCHIVELOG.
- Вы не можете использовать какие-либо методы восстановления данных, которые требуют архивных журналов транзакций. Сюда входят полное восстановление носителя и восстановление носителя на момент времени, о которых я рассказывал в восстановление на момент времени отдельных табличных пространств и Ретроспективная База Данных (в будущем я планирую подробнее рассказать об этих продвинутых возможностях).
Если Вы запускаете базу в режиме NOARCHIVELOG и должны восстановить ее после повреждения файлов данных из-за сбоя диска, Вы имеете две основных опции восстановления:
- Сбросить все объекты, имеющие какие-либо экстенты, расположенные в подверженных воздействию сбоя файлах, и затем сбросить сами эти файлы. Оставшаяся часть базы данных останется нетронутой, но все данные в пораженных файлах будут потеряны. из наиболее позднего бэкапа и потерять все изменения в базе, сделанные с момента взятия этого бэкапа. (Восстановление изменений с момента взятия бэкапа потребовало бы выполнения восстановления носителя, которое использует архивные журналы транзакций.)
Последствия Работы в Режиме ARCHIVELOG
Для большинства приложений, работа в режиме ARCHIVELOG является более предпочтительной по сравнению с работой в режиме NOARCHIVELOG, поскольку Вы имеете более гибкие опции восстановления в случае потери данных, такие как восстановление на момент времени всей базы данных или некоторых табличных пространств. Однако, существуют и связанные с работой в режиме ARCHIVELOG затраты:
- Должно быть выделено пространство в стороне для архивных местоназначений, т.е. локаций на диске, где будут сохраняться архивные журналы транзакций. Эти местоназначения могут стать довольно большими в базах данных с большим количеством обновлений.
- Сохраняемыми архивными журналами изменений необходимо управлять. Чтобы ограничить дисковое пространство, используемое архивными журналами транзакций, эти архивные журналы изменений могут быть перемещены на ленту для длительного хранения, а более старые журналы, которые более не нужны для целей восстановления, следует удалять. (RMAN может автоматизировать большую часть управления архивными журналами транзакций, записывая местоположение и содержимое всех архивных журналов изменений, упрощая перемещение архивных журналов на ленту, и определяя и удаляя журналы транзакций, которые более не нужны для восстановления.)
- Некоторые накладные расходы производительности связаны с фоновыми процессами ARC0 – ARCn, которые копируют заполненные онлайн журналы транзакций в архивные местоположения.
Когда требования производительности зашкаливают или ограничения дискового пространства очень суровые, может статься более предпочтительным работа в режиме NOARCHIVELOG , несмотря на ограничения, которые накладывает этот выбор на опции восстановления.
Взятие Бэкапов Архивных Журналов Транзакций с RMAN
Архивные журналы транзакций – ключ к успешному восстановлению носителя. Резервируйте их регулярно. Можно делать бэкап журналов командой BACKUP ARCHIVELOG , или резервировать журналы при резервном копировании файлов данных и контрольных файлов, указывая BACKUP … PLUS ARCHIVELOG .
Резервирование Файлов Архивных Журналов Транзакций с помощью BACKUP ARCHIVELOG
Чтобы сделать бэкап архивных журналов транзакций, используйте команду BACKUP ARCHIVELOG в командной строке RMAN. Этот пример использует сконфигурированный диск или канал sbt , чтобы зарезервировать по одной копии журнала каждого порядкового номера для всех архивных журналов транзакций:
Даже если Ваши журналы транзакций архивируются в несколько мест назначения, и Вы используете RMAN, чтобы сделать бэкап архивных журналов транзакций, RMAN выбирает только одну копию файла архивного журнала транзакций для включения в набор резервирования. (Так как журналы с тем же самым порядковым номером идентичны, нет необходимости включать более одной копии.)
Можно также указать диапазон архивных журналов транзакций по времени, SCN или по порядковому номеру журнала, как в следующем примере:
Автоматические переключения оперативных журналов транзакций во время бэкапов архивных журналов
Беря резервную копию архивных журналов транзакций, которая включает самый последний журнал (то есть, команда BACKUP … ARCHIVELOG выполняется без опций UNTIL или SEQUENCE ), если база данных открыта, то прежде, чем начать резервное копирование, RMAN переключит текущую онлайновую группу журналов транзакций, и все оперативные журналы транзакций, которые еще не были заархивированы, вплоть до и включая группу журналов транзакций, которая была текущей, когда команда была запущена на выполнение. Это гарантирует, что резервная копия будет содержать все транзакции, которые были сгенерированы до запуска команды.
Использование BACKUP ARCHIVELOG с DELETE INPUT или DELETE ALL INPUT
Можно указать предложения DELETE INPUT или DELETE ALL INPUT для команды BACKUP ARCHIVELOG , чтобы стереть архивные журналы после того, как они будут зарезервированы, избегая отдельный шаг ручного удаления архивных журналов транзакций. При DELETE INPUT RMAN стирает только определенную копию архивного журнала транзакций, выбранную для набора резервирования. При DELETE ALL INPUT RMAN сотрет каждый зарезервированный файл архивного журнала транзакций со всех мест назначения, куда архивируются журналы.
Например, предположим, что журналы архивируются в /arc_dest1 , /arc_dest2 и /arc_dest3 , и Вы выполняете следующую команду:
В этом случае RMAN делает бэкап только одной копии каждого порядкового номера журнала в этих каталогах, а затем стирает все копии всех журналов, которые он зарезервировал, – со всех мест назначения архивации. Если бы Вы указали DELETE INPUT , а не DELETE ALL INPUT , то RMAN стер бы только определенные файлы архивных журналов транзакций, которые он зарезервировал (например, он стер бы файлы архивных журналов транзакций в /arc_dest1, если бы это были файлы, используемые в качестве источника резервного копирования, но оставил бы содержимое /arc_dest2 и /arc_dest3 нетронутым).
Если Вы выпускаете BACKUP ARCHIVELOG ALL или BACKUP ARCHIVELOG LIKE ‘…’ и нет никаких архивных файлов журналов транзакций для резервирования, RMAN не сообщает об ошибке.
Резервирование Журналов с помощью BACKUP … PLUS ARCHIVELOG
Можно добавить архивные журналы транзакций в резервные копии других файлов при помощи предложения BACKUP … PLUS ARCHIVELOG . Добавление BACKUP … PLUS ARCHIVELOG приводит к тому, что RMAN выполняет следующие шаги:
- Запускает команду ALTER SYSTEM ARCHIVE LOG CURRENT .
- Запускает BACKUP ARCHIVELOG ALL . Заметьте, что при включенной оптимизации резервирования диспетчер восстановления пропускает журналы, которые уже были зарезервированы на указанное устройство.
- Резервирует оставшиеся файлы, указанные в команде BACKUP .
- Запускает команду ALTER SYSTEM ARCHIVE LOG CURRENT .
- Резервирует все остальные архивные журналы, сгенерированные во время бэкапа.
Это гарантирует, что резервные копии файлов данных, взятые во время работы команды, можно будет восстановить к согласованному состоянию.
Чтобы сделать бэкап архивных журналов транзакций с помощью BACKUP … PLUS ARCHIVELOG:
После запуска RMAN, выполните команду BACKUP … PLUS ARCHIVELOG в командной строке RMAN. Этот пример резервирует базу данных и все архивные журналы:
Recall from the discussion earlier in my blog that archive redo logs are created only if your Oracle database 12C is in archivelog mode. If you want to preserve your database transaction history to facilitate point-in-time and other types of recovery, you need to enable that mode.
In normal operation, changes to your data generate entries in the database redo log files. As each online redo log group fills up, a log switch is initiated. When a log switch occurs, the log writer process stops writing to the most recently filled online redo log group and starts writing to a new online redo log group. The online redo log groups are written to in a round-robin fashion—meaning the contents of any given online redo log group will eventually be overwritten. Archivelog mode preserves redo data for the long term by employing an archiver background process to copy the contents of a filled online redo log to what is termed an archive redo log file. The trail of archive redo log files is crucial to your ability to recover the Oracle database 12C with all changes intact, right up to the precise point of failure.
Планирование стратегии бэкапа базы – Часть 1 – защита избыточного набора, fra, режимы ARCHIVELOG и NOARCHIVELOG, а также ретроспективные возможности Оракл и точек реставрации
Читайте также: