Что такое redo log oracle
6 Managing the Redo Log
This chapter contains the following topics:
Part III, «Automated File and Storage Management» for information about redo log files that are both created and managed by the Oracle Database server
What Is the Redo Log?
Redo Threads
Redo Log Contents
Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.
Redo records are buffered in a circular fashion in the redo log buffer of the SGA (see «How Oracle Database Writes to the Redo Log») and are written to one of the redo log files by the Log Writer (LGWR) database background process. Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.
Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo records may not be committed. If necessary, the database can roll back these changes.
How Oracle Database Writes to the Redo Log
The redo log of a database consists of two or more redo log files. The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode). See «Managing Archived Redo Logs» for more information.
LGWR writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. Figure 6-1 illustrates the circular writing of the redo log file. The numbers next to each line indicate the sequence in which LGWR writes to each redo log file.
Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled.
If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log file is available after the changes recorded in it have been written to the datafiles.
If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file is available to LGWR after the changes recorded in it have been written to the datafiles and the file has been archived.
Figure 6-1 Reuse of Redo Log Files by LGWR
Description of «Figure 6-1 Reuse of Redo Log Files by LGWR «
Active (Current) and Inactive Redo Log Files
Oracle Database uses only one redo log files at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file.
Redo log files that are required for instance recovery are called active redo log files. Redo log files that are no longer required for instance recovery are called inactive redo log files.
If you have enabled archiving (the database is in ARCHIVELOG mode), then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARC n ) has archived its contents. If archiving is disabled (the database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR continues by overwriting the first available active file.
Log Switches and Log Sequence Numbers
A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.
Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.
Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.
Planning the Redo Log
This section provides guidelines you should consider when configuring a database instance redo log and contains the following topics:
Русские Блоги
Oracle Redo log
Поделитесь учебником по искусственному интеллекту моего учителя! Нулевой фундамент, легко понять!http://blog.csdn.net/jiangjunshow
Вы также можете перепечатать эту статью. Делитесь знаниями, приносите пользу людям и осознайте великое омоложение нашей китайской нации!
Обзор журналов повторов
The redo log records all changes made to data, including both uncommitted and committed changes.
Oracle использует Redo для обеспечения возможности повторения транзакций базы данных, чтобы после сбоя данные можно было восстановить. В базе данных, функции Redo в основном через3 компонентаДля достижения:Redo Log Buffer、LGWR фоновый процессиRedo Log File(В режиме архивирования Redo Log File в конце концов пройдетARCnПроцесс записывается в виде файла архива).
Redo Log Buffer находится в SGA и представляет собой круговую область памяти, в которой хранится информация об изменениях базы данных., Эта информация хранится в форме повторных записей (повторные записи) (повторные записи также часто называются повторными записями). Записи повторов содержат важную информацию для рефакторинга и повторного внесения изменений в базу данных, в том числе INSERT, UPDATE, DELETE, CREATE, ALTER или DROP.
Содержимое записей повторов копируется из области памяти пользователя (PGA) в буфер журналов повторов в SGA с помощью процесса базы данных Oracle。Повторные записи занимают непрерывное последовательное пространство в памятиПоскольку Redo Log Buffer перерабатывается, Oracle непрерывно записывает содержимое Redo Log Buffer в Redo Log File через фоновый процесс LGWR, Redo Log File также перерабатывается.
Используйте сцену
Например, мы сделали резервную копию базы данных вчера вечером, но обнаружили, что диск сегодня сломан в полдень, поэтому как мне его восстановить.
Сначала мы восстановили до вчерашнего вечера через файл резервной копии, а затем восстановили до полудня сегодня через архивированные журналы повторов и онлайн-журналы повторов.
Компонент Redo Log
Redo Log Buffer :Если данные должны быть записаны в оперативный журнал повторов, данные должны быть временно кэшированы в буфере повторов перед записью на диск. Поскольку передача из памяти в память намного быстрее, чем из памяти в диск, использование буфера повторного журнала может ускорить работу базы данных. Время хранения данных в буфере восстановления не будет слишком долгим. Фактически, LGWR запустит сброс этой области, когда возникнет определенная ситуация:
* Всякий раз, когда кто-то отправляет запрос
* Требуется LGWR для переключения файлов журнала
* 1/3 буфера восстановления заполнена или содержит 1 МБ кэшированных данных журнала повторов
LGWR : Запись журнала, LGWR отвечает за обновление содержимого буфера журнала повторов в SGA до фонового процесса на диске.
ARCn: В процессе архивации задачей ARCn является копирование файла онлайн-журнала в другое место, когда LGWR заполняет его. После этого эти архивные файлы журнала повторов можно использовать для завершения восстановления носителя. 。
Принцип Redo Logs
Перед фиксацией операции обновления данных запишите измененный сценарий SQL в журнал повторов. В основном используется для баз данныхИнкрементное резервное копирование и инкрементное восстановление。
Online Redo Logs & ARCHIVE Redo Logs
Журналы повторов делятся на онлайн-журналы повторов и архивированные журналы повторов.
В каждой базе данных Oracle есть как минимум две группы журналов повторного подключения в сети и как минимум один файл журнала повторного выполнения в каждой группе. Эти группы оперативного журнала повторного использования используются циклически. (Пользователи могут добавлять / изменять / удалять группы журналов и файлы журналов для настройки оперативных журналов повторов с помощью операции просмотра.) Содержимое файлов журналов в каждой группе в точности совпадает и хранится в разных местах для зеркального отображения журналов дисков. Несколько резервных копий повышают безопасность. По умолчанию активна только одна группа из этих n групп, и она непрерывно записывает рабочие сценарии синхронно.Когда файл журнала заполнен (заданная квота пространства достигнута), если текущая база данных находится в режиме архивирования, сетевой журнал архивируется на жесткий диск и становится архивным журналом.; Если текущая база данных находится в неархивном режиме, никакая операция архивирования не будет выполнена, а содержимое текущего сетевого журнала будет перезаписано при следующей перезаписи и не может быть сохранено. Поэтому база данных производственной среды обычно находится в режиме архива во время выполнения для сохранения журнала обновления данных. После того, как текущая группа архивных журналов заполнится, Oracle переключится на следующую группу журналов, продолжит запись и, таким образом, переключится циклически: в режиме архивирования переключитесь на исходную полную группу журналов, если группа журналов заархивирована, затем перезапишите Запишите, если нет, вы можете использовать только буфер журнала и подождать, пока архив не будет завершен, прежде чем перезаписывать. Конечно, в неархивном режиме это напрямую перезаписывается.
Архивные файлы журналов повторов фактически являются копиями «старых» файлов онлайн-журналов повторов, которые были заполнены. Когда система заполняет файлы журналов, процесс ARCH создаст копию файла журнала повторов в другом месте, или вы можете создать несколько дополнительных копий в локальном или удаленном местоположении. Если происходит сбой из-за повреждения диска или другого физического сбоя, эти архивные файлы журнала повторного выполнения используются для восстановления носителя.
По умолчанию база данных по умолчанию работает в неархивном режиме, а если она не в архивном режиме, это означает, что у нас нет возможности восстановить базу данных через журнал.
Archived redo logs should be backed up and deleted regularly.
Online redo logs should not be backed up.
LGWR неоднократно записывает файлы журнала повторов. Когда файл журнала заполнен, LGWR записывает файл журнала повторов. Когда последний файл журнала заполнен, LGWR возвращается для записи первого файла журнала.
Reuse of Redo Log Files by LGWR
Online Redo Log File Use in ARCHIVE LOG Mode
Режим архива против режима без архивирования
1. Неархивирующий режим
Неприменимо и производственная база данных
При создании базы данных режимом управления журналом по умолчанию является неархивированный режим.
Когда журнал переключен и контрольная точка сгенерирована, он-лайн файл журнала повторного использования может быть повторно использован
После перезаписи сетевого журнала восстановление носителей поддерживает только самое последнее полное резервное копирование.
Табличное пространство оперативного резервного копирования не поддерживается. Если одно табличное пространство повреждено, вся база данных будет недоступна. Вам необходимо удалить поврежденное табличное пространство или восстановить его из резервной копии.
Для резервного копирования базы данных на уровне операционной системы согласованность базы данных должна быть отключена
Возможность архивирования файлов онлайн-журнала, настоятельно рекомендуется архивировать производственную базу данных.
Когда журнал переключен, следующая группа журналов, в которую нужно записать, должна быть заархивирована, прежде чем можно будет использовать группу журналов.
Информация о порядковом номере журнала архива будет записана в контрольный файл
На диске должно быть достаточно места для хранения архивных журналов.
Oracle 9i должен установить параметр log_archive_start = true, чтобы включить автоматическое архивирование
Резервное копирование и восстановление
Поддерживает горячее резервное копирование, а при повреждении несистемного табличного пространства база данных по-прежнему доступна и поддерживает онлайн-восстановление.
Использование архивных журналов для оперативного или автономного восстановления на определенный момент времени ( Таким образом, вы можете восстановить к указанному моменту времени, указанному архивному журналу или указанному SCN )
V$LOGFILE Хранит место, где находятся журналы Redo
V$LOG displays log file information from the control file.
Посмотрите, включен ли режим архива
Не архивировать в режим архива
B. Загрузиться, чтобы смонтировать сцену
C. Переключиться в режим архива (изменить базу данных archivelog [руководство] )
— Демо не архив в режим архива
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 14
Current log sequence 16
Total System Global Area 251658240 bytes
Fixed Size 1218796 bytes
Variable Size 75499284 bytes
Database Buffers 171966464 bytes
Redo Buffers 2973696 bytes
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 14
Next log sequence to archive 16
Current log sequence 16
Просмотр параметров, связанных с архивом
12 Managing the Redo Log
Chapter 17, «Using Oracle Managed Files» for information about redo log files that are both created and managed by the Oracle Database server
What Is the Redo Log?
Redo Threads
Redo Log Contents
Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.
Redo records are buffered in a circular fashion in the redo log buffer of the SGA (see «How Oracle Database Writes to the Redo Log») and are written to one of the redo log files by the Log Writer (LGWR) database background process. Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.
Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo records may not be committed. If necessary, the database can roll back these changes.
How Oracle Database Writes to the Redo Log
The redo log of a database consists of two or more redo log files. The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode). See «Managing Archived Redo Logs» for more information.
LGWR writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. Figure 12-1 illustrates the circular writing of the redo log file. The numbers next to each line indicate the sequence in which LGWR writes to each redo log file.
Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled.
If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log file is available after the changes recorded in it have been written to the data files.
If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file is available to LGWR after the changes recorded in it have been written to the data files and the file has been archived.
Figure 12-1 Reuse of Redo Log Files by LGWR
Description of «Figure 12-1 Reuse of Redo Log Files by LGWR»
Active (Current) and Inactive Redo Log Files
Oracle Database uses only one redo log file at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file.
Redo log files that are required for instance recovery are called active redo log files. Redo log files that are no longer required for instance recovery are called inactive redo log files.
If you have enabled archiving (the database is in ARCHIVELOG mode), then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARC n ) has archived its contents. If archiving is disabled (the database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR continues by overwriting the next log file in the sequence when it becomes inactive.
Log Switches and Log Sequence Numbers
A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file. However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.
Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.
Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.
Planning the Redo Log
This section provides guidelines you should consider when configuring a database instance redo log and contains the following topics:
Что такое redo log oracle
You manage the redo log by completing tasks such as creating redo log groups and members, relocating and renaming redo log members, dropping redo log groups and members, and forcing log switches.
Using Oracle Managed Files for information about redo log files that are both created and managed by the Oracle Database server
11.1 What Is the Redo Log?
11.1.1 Redo Threads
In typical configurations, only one database instance accesses an Oracle Database, so only one thread is present. In an Oracle Real Application Clusters environment, however, two or more instances concurrently access a single database and each instance has its own thread of redo. A separate redo thread for each instance avoids contention for a single set of redo log files, thereby eliminating a potential performance bottleneck.
11.1.2 Redo Log Contents
Redo entries record data that you can use to reconstruct all changes made to the database, including the undo segments. Therefore, the redo log also protects rollback data. When you recover the database using redo data, the database reads the change vectors in the redo records and applies the changes to the relevant blocks.
Redo records are buffered in a circular fashion in the redo log buffer of the SGA (see «How Oracle Database Writes to the Redo Log» ) and are written to one of the redo log files by the Log Writer (LGWR) database background process. Whenever a transaction is committed, LGWR writes the transaction redo records from the redo log buffer of the SGA to a redo log file, and assigns a system change number (SCN) to identify the redo records for each committed transaction. Only when all redo records associated with a given transaction are safely on disk in the online logs is the user process notified that the transaction has been committed.
Redo records can also be written to a redo log file before the corresponding transaction is committed. If the redo log buffer fills, or another transaction commits, LGWR flushes all of the redo log entries in the redo log buffer to a redo log file, even though some redo records may not be committed. If necessary, the database can roll back these changes.
11.1.3 How Oracle Database Writes to the Redo Log
The redo log for a database consists of two or more redo log files. The database requires a minimum of two files to guarantee that one is always available for writing while the other is being archived (if the database is in ARCHIVELOG mode).
LGWR writes to redo log files in a circular fashion. When the current redo log file fills, LGWR begins writing to the next available redo log file. When the last available redo log file is filled, LGWR returns to the first redo log file and writes to it, starting the cycle again. Figure 11-1 illustrates the circular writing of the redo log file. The numbers next to each line indicate the sequence in which LGWR writes to each redo log file.
Filled redo log files are available to LGWR for reuse depending on whether archiving is enabled.
If archiving is disabled (the database is in NOARCHIVELOG mode), a filled redo log file is available after the changes recorded in it have been written to the data files.
If archiving is enabled (the database is in ARCHIVELOG mode), a filled redo log file is available to LGWR after the changes recorded in it have been written to the data files and the file has been archived.
Figure 11-1 Reuse of Redo Log Files by LGWR
Description of «Figure 11-1 Reuse of Redo Log Files by LGWR»
11.1.3.1 Active (Current) and Inactive Redo Log Files
Oracle Database uses only one redo log file at a time to store redo records written from the redo log buffer. The redo log file that LGWR is actively writing to is called the current redo log file.
Redo log files that are required for instance recovery are called active redo log files. Redo log files that are no longer required for instance recovery are called inactive redo log files.
If you have enabled archiving (the database is in ARCHIVELOG mode), then the database cannot reuse or overwrite an active online log file until one of the archiver background processes (ARC n ) has archived its contents. If archiving is disabled (the database is in NOARCHIVELOG mode), then when the last redo log file is full, LGWR continues by overwriting the next log file in the sequence when it becomes inactive.
11.1.3.2 Log Switches and Log Sequence Numbers
A log switch is the point at which the database stops writing to one redo log file and begins writing to another. Normally, a log switch occurs when the current redo log file is completely filled and writing must continue to the next redo log file.
However, you can configure log switches to occur at regular intervals, regardless of whether the current redo log file is completely filled. You can also force log switches manually.
Oracle Database assigns each redo log file a new log sequence number every time a log switch occurs and LGWR begins writing to it. When the database archives redo log files, the archived log retains its log sequence number. A redo log file that is cycled back for use is given the next available log sequence number.
Each online or archived redo log file is uniquely identified by its log sequence number. During crash, instance, or media recovery, the database properly applies redo log files in ascending order by using the log sequence number of the necessary archived and redo log files.
11.2 Planning the Redo Log
You can follow guidelines when configuring a database instance redo log.
11.2.1 Multiplexing Redo Log Files
To protect against a failure involving the redo log itself, Oracle Database allows a multiplexed redo log, meaning that two or more identical copies of the redo log can be automatically maintained in separate locations.
For the most benefit, these locations should be on separate disks. Even if all copies of the redo log are on the same disk, however, the redundancy can help protect against I/O errors, file corruption, and so on. When redo log files are multiplexed, LGWR concurrently writes the same redo log information to multiple identical redo log files, thereby eliminating a single point of redo log failure.
Multiplexing is implemented by creating groups of redo log files. A group consists of a redo log file and its multiplexed copies. Each identical copy is said to be a member of the group. Each redo log group is defined by a number, such as group 1, group 2, and so on.
Figure 11-2 Multiplexed Redo Log Files
Description of «Figure 11-2 Multiplexed Redo Log Files»
In Figure 11-2, A_LOG1 and B_LOG1 are both members of Group 1, A_LOG2 and B_LOG2 are both members of Group 2, and so forth. Each member in a group must be the same size.
Oracle recommends that you multiplex your redo log files. The loss of the log file data can be catastrophic if recovery is required. Note that when you multiplex the redo log, the database must increase the amount of I/O that it performs. Depending on your configuration, this may impact overall database performance.
11.2.1.1 Responding to Redo Log Failure
Whenever LGWR cannot write to a member of a group, the database marks that member as INVALID and writes an error message to the LGWR trace file and to the database alert log to indicate the problem with the inaccessible files.
The specific reaction of LGWR when a redo log member is unavailable depends on the reason for the lack of availability, as summarized in the table that follows.
LGWR can successfully write to at least one member in a group
Writing proceeds as normal. LGWR writes to the available members of a group and ignores the unavailable members.
LGWR cannot access the next group at a log switch because the group must be archived
Database operation temporarily halts until the group becomes available or until the group is archived.
All members of the next group are inaccessible to LGWR at a log switch because of media failure
Oracle Database returns an error, and the database instance shuts down. In this case, you may need to perform media recovery on the database from the loss of a redo log file.
If the database checkpoint has moved beyond the lost redo log, media recovery is not necessary, because the database has saved the data recorded in the redo log to the data files. You need only drop the inaccessible redo log group. If the database did not archive the bad log, use ALTER DATABASE CLEAR LOGFILE UNARCHIVED to disable archiving before the log can be dropped.
All members of a group suddenly become inaccessible to LGWR while it is writing to them
Oracle Database returns an error and the database instance immediately shuts down. In this case, you may need to perform media recovery. If the media containing the log is not actually lost—for example, if the drive for the log was inadvertently turned off—media recovery may not be needed. In this case, you need only turn the drive back on and let the database perform automatic instance recovery.
11.2.1.2 Legal and Illegal Configurations
In most cases, a multiplexed redo log should be symmetrical: all groups of the redo log should have the same number of members. However, the database does not require that a multiplexed redo log be symmetrical.
For example, one group can have only one member, and other groups can have two members. This configuration protects against disk failures that temporarily affect some redo log members but leave others intact.
The only requirement for an instance redo log is that it have at least two groups. Figure 11-3 shows legal and illegal multiplexed redo log configurations. The second configuration is illegal because it has only one group.
Figure 11-3 Legal and Illegal Multiplexed Redo Log Configuration
Description of «Figure 11-3 Legal and Illegal Multiplexed Redo Log Configuration»
11.2.2 Placing Redo Log Members on Different Disks
When setting up a multiplexed redo log, place members of a group on different physical disks. If a single disk fails, then only one member of a group becomes unavailable to LGWR and other members remain accessible to LGWR, so the instance can continue to function.
If you archive the redo log, spread redo log members across disks to eliminate contention between the LGWR and ARC n background processes. For example, if you have two groups of multiplexed redo log members (a duplexed redo log), place each member on a different disk and set your archiving destination to a fifth disk. Doing so will avoid contention between LGWR (writing to the members) and ARC n (reading the members).
Data files should also be placed on different disks from redo log files to reduce contention in writing data blocks and redo records.
11.2.3 Planning the Size of Redo Log Files
When setting the size of redo log files, consider whether you will be archiving the redo log. Redo log files should be sized so that a filled group can be archived to a single unit of offline storage media (such as a tape or disk), with the least amount of space on the medium left unused.
For example, suppose only one filled redo log group can fit on a tape and 49% of the tape storage capacity remains unused. In this case, it is better to decrease the size of the redo log files slightly, so that two log groups could be archived on each tape.
All members of the same multiplexed redo log group must be the same size. Members of different groups can have different sizes. However, there is no advantage in varying file size between groups. If checkpoints are not set to occur between log switches, make all groups the same size to guarantee that checkpoints occur at regular intervals.
The minimum size permitted for a redo log file is 4 MB.
Your operating system–specific Oracle documentation. The default size of redo log files is operating system dependent.
11.2.4 Planning the Block Size of Redo Log Files
Unlike the database block size, which can be between 2K and 32K, redo log files always default to a block size that is equal to the physical sector size of the disk. Historically, this has typically been 512 bytes (512B).
Some newer high-capacity disk drives offer 4K byte (4K) sector sizes for both increased ECC capability and improved format efficiency. Most Oracle Database platforms are able to detect this larger sector size. The database then automatically creates redo log files with a 4K block size on those disks.
However, with a block size of 4K, there is increased redo wastage. In fact, the amount of redo wastage in 4K blocks versus 512B blocks is significant. You can determine the amount of redo wastage by viewing the statistics stored in the V$SESSTAT and V$SYSSTAT views.
To avoid the additional redo wastage, if you are using emulation-mode disks—4K sector size disk drives that emulate a 512B sector size at the disk interface—you can override the default 4K block size for redo logs by specifying a 512B block size or, for some platforms, a 1K block size. However, you will incur a significant performance degradation when a redo log write is not aligned with the beginning of the 4K physical sector. Because seven out of eight 512B slots in a 4K physical sector are not aligned, performance degradation typically does occur. Thus, you must evaluate the trade-off between performance and disk wastage when planning the redo log block size on 4K sector size emulation-mode disks.
The following statement adds a redo log file group with a block size of 512B. The BLOCKSIZE 512 clause is valid but not required for 512B sector size disks. For 4K sector size emulation-mode disks, the BLOCKSIZE 512 clause overrides the default 4K size.
To ascertain the redo log file block size, run the following query:
Oracle Database SQL Language Reference for information about the ALTER DATABASE command.
Oracle Database Reference for information about the V$SESSTAT view
Oracle Database Reference for information about the V$SYSSTAT view
11.2.5 Choosing the Number of Redo Log Files
The best way to determine the appropriate number of redo log files for a database instance is to test different configurations. The optimum configuration has the fewest groups possible without hampering LGWR from writing redo log information.
In some cases, a database instance may require only two groups. In other situations, a database instance may require additional groups to guarantee that a recycled group is always available to LGWR. During testing, the easiest way to determine whether the current redo log configuration is satisfactory is to examine the contents of the LGWR trace file and the database alert log. If messages indicate that LGWR frequently has to wait for a group because a checkpoint has not completed or a group has not been archived, add groups.
Consider the parameters that can limit the number of redo log files before setting up or altering the configuration of an instance redo log. The following parameters limit the number of redo log files that you can add to a database:
Your operating system specific Oracle documentation for the default and legal values of the MAXLOGFILES and MAXLOGMEMBERS parameters