Fra oracle что это
При попытке осуществить резервное копирование вашей базы данных с помощью RMAN у вас выдаётся ошибка:
Включение режима архивации базы данных
Проверка установки режима архивации
Для проверки установки режима архивации можно сделать следующий запрос к представлению V$DATABASE:
Команда archive log утилиты SQL*Plus так же показывает состояние режима архивирования. В дополнение она выводит информацию о режиме архивирования, состоянии флага автоматического архивирования, месте назначения архивных журнальных файлов и значениях последовательностей журналов.
Oracle DBA
Лучше потратить какое-то количество времени, чтобы записать успешный опыт, чем потом повторно воспроизводить его по памяти.
Все материалы обновляются по мере нахождения лучших практик и апгрейда знаний. Если будут желающие добавлять свои знания или исправлять ошибки и неточности, пишите в телеграм чате. Если будет учавствовать больше людей, качество материалов будет улучшаться и обновляться быстрее. Ссылки на ваши профили в соц. сетях будут добавлены в статьях, в которых вы учавствуете.
Oracle Database Backup and Recovery Reference for the syntax and semantics of RMAN commands
9.1 Overview of Database Backup and Recovery
The focus in Oracle Database backup and recovery is on the physical backup of database files, which permits you to reconstruct your database.
Oracle Recovery Manager (RMAN), a command-line tool, is the method preferred by Oracle for efficiently backing up and recovering your Oracle database. The files protected by the backup and recovery facilities built into RMAN include data files, control files, server parameter files, and archived redo log files. With these files you can reconstruct your database. RMAN is designed to work intimately with the server, providing block-level corruption detection during backup and restore. RMAN optimizes performance and space consumption during backup with file multiplexing and backup set compression, and integrates with leading tape and storage media products. The backup mechanisms work at the physical level to protect against file damage, such as the accidental deletion of a data file or the failure of a disk drive. RMAN can also be used to perform point-in-time recovery to recover from logical failures when other techniques such as flashback cannot be used.
Logical backups, such as exporting database objects such as tables or tablespaces, are a useful supplement to physical backups, but cannot protect your whole database. An effective backup strategy must be based on physical backups.
The Oracle Database flashback features provide a range of physical and logical data recovery tools as efficient, easy-to-use alternatives to physical and logical backups. The flashback features enable you to reverse the effects of unwanted database changes without restoring data files from backup.
This section provides links to the following flashback features that are documented in Oracle Database Backup and Recovery User’s Guide :
Oracle Flashback Table, which enables you to revert a table to its contents at a time in the recent past
Oracle Flashback Drop, which enables you to retrieve deleted (dropped) database tables
Oracle Flashback Database, which enables you to revert the entire database to a past point in time
The first two features operate at the logical level, whereas the last feature operates at the physical level. None of the preceding features requires advance preparation such as creating logical exports to allow for retrieval of your lost data, but Oracle Flashback Database requires the advance preparation of enabling the feature. You can use all of the features while your database is available. Oracle Database Backup and Recovery User’s Guide discusses the flashback features of Oracle Database at greater length.
Oracle Flashback Database does not recover missing data files.
9.1.1 Overview of Backing Up and Recovering CDBs and PDBs
When using the multitenant architecture, you can perform backup and recovery operations on a whole multitenant container database (CDB), the root, or one or more pluggable databases (PDBs).
The Oracle Recovery Manager (RMAN) commands used to backup and recover CDBs and PDBs are the same as those used for non-CDBs, with minor variations in the syntax. The backup and recovery operations performed on non-CDBs can also be performed on CDBs and PDBs. This includes the following:
Full and incremental backups
Complete and point-in-time recovery (PITR)
Reporting operations (such as listing backups and cross-checking backups)
About Connecting to CDBs and PDBs
You can connect to the root in one of the following ways :
Connect using operating system authentication
You are connected to the root as the SYS user with the SYSDBA privilege.
Connect locally as a common user
Connect as a common user through Oracle Net Services
To connect as TARGET to a PDB, use one of the following techniques:
Connect with a net service name that resolves to a database service for that PDB
Connect locally as a common user or local user with the SYSDBA or SYSBACKUP privilege
Certain operations are not available when you connect directly to a PDB. See Oracle Database Backup and Recovery User’s Guide for a list of these operations.
The following sections in the Oracle Database Backup and Recovery User’s Guide provide detailed information about backing up and recovering PDBs:
9.1.1.1 Backup and Complete Recovery of CDBs
To perform backup and complete recovery operations on a whole multitenant container database (CDB), you connect as TARGET to the root.
The connection must be established as a common user with the SYSDBA or SYSBACKUP privilege.
After you connect to the root, the same commands that are used to perform operations on non-CDBs are used to perform backup and complete recovery on the entire CDB.
The following sections in the Oracle Database Backup and Recovery User’s Guide provide detailed information about performing backup and complete recovery of CDBs:
9.1.1.2 Backup and Complete Recovery of PDBs
You can perform backup and complete recovery operations on a single pluggable database (PDB) or on multiple PDBs.
Backups of PDBs
When relocating a PDB or cloning a non-CDB as a PDB, you may want to retain the use of preplugin backups. For preplugin backups to be usable in the destination CDB, metadata about the preplugin backups must be exported to the RMAN repository of the destination CDB.
The technique for making the backups usable depends on the type of operation:
Creating a PDB by cloning a non-CDB
When the non-CDB is opened in read/write mode, you must execute the DBMS_PDB.EXPORTRMANBACKUP procedure as the last step before cloning. When plugging in the non-CDB as a PDB to a destination CDB, the operation copies the backup metadata of the source non-CDB into the data dictionary of the destination CDB.
Relocating a PDB to another CDB
When you unplug the source PDB, the backup metadata is automatically exported. Therefore, you do not need to execute DBMS_PDB.EXPORTRMANBACKUP .
Preplugin backups are usable only on the destination CDB into which you plug in the source non-CDB or PDB.
Oracle Database Backup and Recovery User’s Guide to learn how to create a preplugin backup of the whole database
Oracle Database PL/SQL Packages and Types Reference to learn more about the DBMS_PDB.EXPORTRMANBACKUP procedure
Syntax for Backup Commands
Although the Oracle Recovery Manager (RMAN) commands are the same, the syntax used to perform operations on multiple PDBs contains some modifications.
To perform backup and complete recovery operations on a single PDB, you can connect as TARGET to either of the following containers:
In this case, use the same commands that you would use to backup or recover non-CDBs. For example, to back up a PDB, use the BACKUP DATABASE command.
In this case, use the PLUGGABLE DATABASE clause in your RMAN commands. The following command backs up the PDB hrpdb when connected to the root:
To perform backup and complete recovery operations on multiple PDBs using a single command, you must connect to the root. Use the PLUGGABLE DATABASE clause followed by the list of PDBs on which you want to perform the operation. The following example backs up the PDBs hrpdb , salespdb , and invpdb when connected to the root:
The following sections in the Oracle Database Backup and Recovery User’s Guide provide detailed information about backing up and recovering PDBs:
- Главная /
- Статьи /
- Oracle /
- RMAN В ПРИМЕРАХ - Использование флэш-области восстановления. Глава 2. Часть 1
2-2. Запись регулярных копий базы данных в флэш-область восстановления.
Флэш-область восстановления создана. Используем её для создания резервных копий.
Копирование базы в флэш-область восстановления
Создадим резервную копию базы данных в флэш-области восстановления, не используя опции форматирования:
Так как мы не указывали никаких опций форматирования, резервные копии базы данных по умолчанию создаются в каталоге флэш-области восстановления. Файлы резервных копий помещаются в специально созданные подкаталоги этого каталога. Так, вначале создаётся подкаталог, соответствующий имени экземпляра копируемой базы данных. Затем в этом подкаталоге создаётся ещё один подкаталог с именем backupset. Далее в нём создаётся подкаталог с именем даты создаваемой резервной копии. После чего, в него помещаются два файла. Файлы представляют собой наборы резервных копий в упакованном внутреннем формате. Первый набор содержит все файлы данных базы. Второй включает контрольные файлы и двоичный файл параметров.
RMAN В ПРИМЕРАХ - Использование флэш-области восстановления. Глава 2. Часть 1
Начиная с первого релиза 10g в Oracle можно определить специальную область на диске, называемую флэш-областью восстановления (FRA), которая используется базой данных как резервное местоположение. По умолчанию, RMAN создает в FRA резервные копии всех типов - регулярных резервных копий, копий образов, журнальных архивных файлов. Так как RMAN знает о существовании этой области, это позволяет ему автоматически удалять ненужные избыточные или устаревшие резервные копии, чтобы освободить место для новых копий.
Оперативные файлы журналов повтора (Online Redo Log Files)
Оперативные файлы журналов повтора - предназначены для записи всех изменений, выполненных над данными базы данных Oracle. Используется для хранения на диске информации для повторного выполнения операций.
Для компьютера выполнить задачи повторно - означает выполнить ее точно так, как она выполнялась в предыдущий раз. Поэтому назначение оперативного файла журнала повтора заключается в сохранении информации об изменениях в базе данных таким, образом, чтобы позже их можно было повторить.
Каждая база данных должна иметь не менее двух оперативных файлов журналов повтора. Текущий файл постепенно заполняется, после его заполнения (или переключения некоторыми командами), база данных приступает к записи в следующий файл. Эта операция называется переключением журналов.
Поскольку файлы повтора необходимы для выполнения восстановления базы данных и являются критичными, их объединяют в группы. Запись происходит одновременно в файлы одной группы.
2-3. Освобождение пространства в флэш-области восстановления
Если флэш-область восстановления исчерпала выделенное ей свободное дисковое пространство, то вы будете наблюдать в журнале регистрации alert log запись примерно такого вида:
Игнорирование этого предупреждения может привести к остановке процесса архивации и невозможности в дальнейшем открытия экземпляра базы данных при перезагрузке. Для исправления ситуации, в этом случае, можно осуществить любые из следующих действий.
Увеличение пространства флэш-области восстановления
Можно динамически увеличить место, выделяемое под флэш-область восстановления, с помощью следующей команды:
Удаление контрольных точек
Можно удалить созданные ранее контрольные точки
Это позволит освободить немного места и стартовать базу данных.
Выключение FlashBack
Если первые два способа не привели к положительным результатам или являются неприемлемыми, можно временно отключить FlashBack:
Это позволит остановить flashback операции и не генерировать flashback лог. После этого мы можем удалить ненужные резервные копии и архивные журнальные файлы:
Теперь можно открывать базу данных:
Учитывайте, что выключение FlashBack не удаляет пространство, занятое гарантийными контрольными точками.
Необязательные файлы:
-
(необязательные в том смысле, что база может быть настроена для работы без данных файлов) (Alertlog - если нет необходимости в изучении данных по ошибкам, можно удалить. Трассировочные файлы по умолчанию не создаются. Чтобы создавались, нужно включать трассировку и потом не забыть отключить) (По умолчанию не используются. Нужно специально создавать специальными командами.)
2-4. Проверка используемого пространства в флэш-области восстановления
После настройки флэш-области восстановления требуется посмотреть общее пространство, занимаемое этой областью, а также пространство, занимаемое по отдельности каждым составляющим её файлом. Для решения этой задачи можно использовать следующие представления.
Представление v$recovery_file_dest показывает дисковую квоту и использование дискового пространства в флэш-области восстановления:
- NAME - директория используемая для местоположения флэш-области. Значение соответствует параметру DB_RECOVERY_FILE_DEST.
- SPACE_LIMIT- максимальное количество дискового пространства (в байтах), который база данных может использовать для области восстановления вспышки. Значение соответствует параметру DB_RECOVERY_FILE_DEST_SIZE.
- SPACE_USED - количество дискового пространства (в байтах) используемого файлами флэш-области восстановления. Изменение флэш-области восстановления не сбрасывает это значение в 0.
- SPACE_RECLAIMABLE- общий размер дискового пространства (в байтах), который может быть создан, удаляя устаревшие, избыточные, или другие файлы низкого приоритета из флэш-области восстановления.
- NUMBER_OF_FILES -общее количество файлов в флэш-области.
Представление v$flash_recovery_area_usage показывает процент использование дискового пространства для различных типов файлов флэш-области восстановления:
- FILE_TYPE - тип файла флэш-области.
- PERCENT_SPACE_USED - процент дискового пространства используемого данным типом файла флэш-области восстановления в процентах от общего размера дискового пространства флэш-области.
- PERCENT_SPACE_RECLAIMABLE - процент дискового пространства , который может быть создан, удаляя устаревшие, избыточные, или другие файлы низкого приоритета из флэш-области восстановления для данного типа файла в процентах от общего размера дискового пространства флэш-области.
- NUMBER_OF_FILES - количество файлов в флэш-области восстановления.
Для того чтобы видеть общий размер пространства каждого файла флэш-области восстановления, надо соединить представление v$flash_recovery_area_usage с представлением recovery_file_dest.
Управляющие файлы (Control Files)
Поскольку база данных Oracle является физическим набором связанных файлов данных, то для их синхронизации и контроля требуется особые методы. Для этих целей используются управляющие файлы.
База данных Oracle может иметь один или несколько управляющих файлов. Если имеется несколько управляющих файлов, все они должны быть абсолютно идентичными. При каждом запуске базы данных Oracle читает информацию управляющего файла, а при каждом изменении размещения или добавления новых файлов данных и журналов базы данных обновляет управляющий файл.
1-2. Подключение к RMAN
Локальное подключение
Подключение подразумевает, что вы вошли в операционную систему, используя учётную запись oracle.
Локальное подключение с использованием имени и пароля
При подключении используется файл паролей.
Удалённое подключение
Подключение возможно только для пользователей с sysdba привилегией или пользователей использующих файл паролей.
Архивные файлы журналов повтора (Archive Log Files)
Как только оперативный файл журнала повтора (Redolog) оказывается заполнен, программное обеспечение сервера Oracle начинает запись в следующий файл. Эта операция повторяется, как следствие информация в оперативных файлах журнала (Redolog) многократно перезаписывается.
Если необходимо сохранить историю изменений, нужно, чтобы после переключения журналов сохранялась их копия. Для этого достаточно перевести работу базы данных в режим работы ARCHIVELOG.
Архивные файлы журналов повтора жизненно важны при восстановлении. Если часть базы данных потеряна или повреждена, то для устранения повреждений обычно требуется несколько архивных журналов или туева хуча этих журналов. Файлы журналов повтора должны применяться к базе данных последовательно. Если один из архивных файлов журналов повтора пропущен, то остальные архивные файлы журналов не могут использоваться. Храните все свои архивные файлы журналов повтора с момента выполнения последней резервной копии. Файлы журналов постепенно накапливаются и разрастаются. Иногда необходимо их удалять. Все операции с данными файлами по применению их к базе выполняются исключительно средствами базы данных. А копировать и переносить их при желании можно как угодно. Бездумно удалять их руками не рекомендуется.
1-5. Восстановление базы данных
Требуется восстановить базу данных после произошедшего сбоя. Учитываем, что имеется не повреждённая резервная копия, а так же имеются все контрольные файлы, архивные и оперативные журналы.
Восстановление всех файлов базы данных из копии
Для восстановления базы данных необходимо смонтировать экземпляр и запустить команду restore database:
Команда восстановила файлы данных из резервной копии.
Применение изменений к файлам базы данных
Следующим шагом осуществляется применение изменений в базе данных произошедших в интервал времени с момента создания резервной копии и до времени сбоя:
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-2. Подключение к RMAN
Локальное подключение
Подключение подразумевает, что вы вошли в операционную систему, используя учётную запись oracle.
Локальное подключение с использованием имени и пароля
При подключении используется файл паролей.
Удалённое подключение
Подключение возможно только для пользователей с sysdba привилегией или пользователей использующих файл паролей.
2-1. Создание флэш-области
Требуется создать флэш-область для базы данных.
Выключение параметров log_archive_dest и log_archive_duplex_dest
Для начала надо отключить параметры log_archive_dest и log_archive_duplex_dest, если конечно они установлены:
Если при изменении значения параметров возникает ошибка:
То, необходимо отключить использование флэш-области, выполнив следующую команду:
Не забудьте при этом перезагрузить экземпляр.
Задание размеров и создание флэш-области восстановления
Команды должны выполняться в строгой последовательности.
Каталог флэш-области восстановления должен существовать до выполнения команды.
Теперь флэш-область создана и готова к работе.
Файлы данных (Data Files)
Все данные в базе данных Oracle сохраняются в файлах данных. Все таблицы, индексы, триггеры, последовательности, программы на PL/SQL, представления - все это находится в файлах данных. И хотя эти и другие объекты базы данных логически содержатся в табличных пространствах, в действительности они сохраняются в файлах на жестком диске компьютера.
В каждой базе данных Oracle имеется по крайней мере один файл данных (но обычно их бывает больше). Если вы создаете в Oracle таблицу и заполняете ее строками, Oracle помещает эту таблицу и строки в файл данных. Каждый файл данных может быть связан только с одной базой данных.
У каждого файла данных имеется специальный формат, внутренний для программного обеспечения Oracle. Важно отдавать себе отчет в том, что файл данных состоит из заголовка и совокупности блоков. Заголовок файла данных Oracle содержит несколько структур, в том числе и идентификатор базы данных, номер и имя файла, тип файла, SCN создания и состояния файла.
Данные в файлы вносятся исключительно средствами Oracle.
Следующий запрос, покажет, где находятся файлы данных.
Обязательные файлы:
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.
Файлы паролей (Password File)
Необязательный файл, используется для защиты информации о подключениях привилегированных пользователей. Если отсутствует, то вы можете выполнять администрирование своей базы данных, только локально. Кроме того, с его помощью контролируется количество привилегированных подключений для управления в одно и то же время.
Tags: Oracle Database, Файлы базы данных Oracle,
2-5. Расширение или уменьшение флэш-области восстановления.
Иногда может потребоваться увеличение размера флэш-области восстановления. Обычно такая операция необходима при росте базы данных или увеличении периода хранения резервных копий.
Увеличение размера флэш-области
Уменьшение размера флэш-области
Обычно, при уменьшении размера флэш-области, если используемое дисковое пространство (столбец SPACE_USED) превышает лимит флэш-области (столбец SPACE_LIMIT), то устаревшие и избыточные файлы будут автоматически удалены. При этом, максимальный размер пространства, которое может быть удалено отображается в столбце SPACE_RECLAIMABLE. Если этого количества, по каким-то причинам недостаточно, то чтобы привести в соответствие размеры доступного и занятого дискового пространства в флэш-области, файлы не удаляются и размер занятого пространства в этом случае остается без изменений:
Попытка сделать в этот момент резервную копию, даже очень небольшую закончиться ошибкой следующего вида:
Если при удалении избытычных резервных копий не требуется диалога запроса, то можно использовать следующую команду:
Результатом проведённого удаления лишних резервных копий является уменьшение размера занятого дискового пространства флэш-области:
Файлы параметров pfile, spfie (Parameter Files)
Файлы параметров используются для конфигурирования действий Oracle предже всего при старте. Для того, чтобы запустить экземпляр базы данных, Oracle должен прочесть файл параметров и определить, какие параметры инициализации установлены для этого экземпляра. В файле параметров содержатся многочисленные параметры и их установленные значения. Oracle считывает файл параметров при запуске базы данных. Можно создать несколько файлов параметров, каждый будет соответствовать различным конфигурациям экземпляра.
- spfile - бинарный файл, который используется сервером Oracle при старте.
- pfile - текстовый файл с параметрами, будет использоваться при старте, если не будет найден spfile.
При старте, Oracle считает файл spfileora112.ora. (файл серверных параметров). Преимущество spfile заключается в том, что при работе с базой данных, любые изменения в базе касающиеся изменения параметра системы, автоматически записываются в данный файл.
Если используется pfile, для сохранения изменений, необходимо либо “руками вносить эти изменения” в текстовый файл, либо в консоли выполнять команды для создания данных файлов Ораклом.
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.
1-4. Симуляция отказа
Следующий пример демонстрирует симуляцию отказа базы данных, путём переименования одного из файлов базы данных, и последующее восстановление базы данных из резервной копии.
Просмотр расположения файлов базы данных
Для начала определим местоположение будущего переименованного файла (example01.dbf). Это можно сделать с помощью команды RMAN report schema:
Остановка базы данных
Остановим базу данных:
Переименование файла базы данных
Для симуляции отказа базы данных переименуем файл example01.dbf:
Запуск базы данных
Стартуем повреждённую базу данных:
База данных не сможет быть открыта пока файл данных example01.dbf не будет восстановлен.
Как я могу узнать, что моя база данных использует PFILE или SPFILE?
Выполните следующий запрос, чтобы увидеть какой файл параметров был использован:
1-3. Копирование базы
Простое копирование базы данных.
Копирование всей базы
Выполнение копирования всей базы данных с помощью команды backup:
Просмотр информации об копии
Если в выводимой информации требуется отображать время, можно определить формат даты, используя переменную среды NLS_DATE_FORMAT:
Alert log и трассировочные файлы (trace file)
При работе базы данных события и ошибки регистрируются в текстовых файлах на сервере базы данных. Файл журнала предупреждений (alert log) нужен администратору базы данных для отслеживания важнейших действий с базой данных - наподобие открытия и закрытия базы данных, установления параметров загрузки базы данных и переключения оперативных журналов повтора. Также в эти файлы записываются многие ошибки базы данных для последующего расследования их причин. Любые структурные изменения базы данных также регистрируются в файле журнала предупреждений.
Когда возникает ошибка базы данных, может генерироваться файл трассировки (trace file). Они содержит подробную информацию о возникновении ошибки.
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.
Предполагается, что вы инсталлировали базу данных, согласно документа.
Читайте также: