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 shows legal and illegal multiplexed redo log configurations. The second configuration is illegal because it has only one group. 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.
Data files should also be placed on different disks from redo log files to reduce contention in writing data blocks and redo records. 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.
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. Your operating system—specific Oracle documentation. The default size of redo log files is operating system dependent. 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 bytes B. 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 B blocks is significant. To avoid the additional redo wastage, if you are using emulation-mode disks—4K sector size disk drives that emulate a B sector size at the disk interface—you can override the default 4K block size for redo logs by specifying a B 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 B 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.
On some platforms, the permissible block sizes are and On other platforms, the permissible block sizes are and The following statement adds a redo log file group with a block size of B. 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:. Therefore, it is important to consider this limit before creating a database. You can force all enabled redo log threads to switch their current logs at regular time intervals. The changes that are being applied by the standby database can lag behind the changes that are occurring on the primary database, because the standby database must wait for the changes in the primary database redo log to be archived into the archived redo log and then shipped to it.
Setting this parameter lets you specify in seconds how long that lag can be. In an Oracle Real Application Clusters environment, the instance also causes other threads to switch and archive their logs if they are falling behind.
Because the estimated archival time is also considered, this is not the exact log switch time. The following initialization parameter setting sets the log switch interval to 30 minutes a typical value. Failing to do so results in unpredictable behavior. Parent topic: Controlling Archive Lag. However, in the case of irregularities of redo generation speed, the interval does provide an upper limit for the time range each current log covers.
This can force frequent log switches. Set the parameter to a reasonable value so as not to degrade the performance of the primary database. Plan the redo log for a database and create all required groups and members of redo log files during database creation.
However, there are situations where you might want to create additional groups or members. For example, adding groups to a redo log can correct redo log group availability problems.
Provide full path names of new log members to specify their location. Otherwise, the files are created in either the default or current directory of the database server, depending upon your operating system. Using group numbers can make administering redo log groups easier. Do not skip redo log file group numbers that is, do not number your groups 10, 20, 30, and so on , or you will consume unnecessary space in the control files of the database.
In some cases, it might not be necessary to create a complete group of redo log files. A group could already exist, but not be complete because one or more members of the group were dropped for example, because of a disk failure.
In this case, you can add new members to an existing group. Notice that file names must be specified, but sizes need not be. The size of the new members is determined from the size of the existing members of the group.
Fully specify the file names of new log members to indicate where the operating system files should be created. Otherwise, the files will be created in either the default or current directory of the database server, depending upon your operating system. This is normal and it will change to active blank when it is first used.
This procedure is necessary, for example, if the disk currently used for some redo log files is going to be removed, or if data files and several redo log files are stored on the same disk and should be separated to reduce contention.
Additionally, you might also need operating system privileges to copy files to the desired location and privileges to open and back up the database. Before relocating your redo logs, or making any other structural changes to the database, completely back up the database in case you experience problems while performing the operation. As a precaution, after renaming or relocating a set of redo log files, immediately back up the database control file.
Use the following steps for relocating redo logs. The example used to illustrate these steps assumes:. The log files are located on two disks: diska and diskb. The redo log files located on diska must be relocated to diskc. Operating system files, such as redo log members, must be copied using the appropriate operating system commands.
See your operating system specific documentation for more information about copying files. Some operating systems allow you to use a character in place of the word HOST. For example, you can use an exclamation point! The following example uses operating system commands UNIX to move the redo log members to a new location:. For example, you want to reduce the number of groups in an instance redo log. In a different case, you may want to drop one or more specific redo log members.
For example, if a disk failure occurs, you may need to drop all the redo log files on the failed disk so that the database does not try to write to the inaccessible files. By default, a log switch occurs automatically when the current redo log file group fills. When a log switch occurs, the log writer lgwr process stops writing to the current redo log group and starts writing to the next available redo log group.
You can force a log switch to make the current redo group inactive and available for redo log maintenance operations. For example, you might want to drop the current redo group but are not able to do so until the group is inactive. You may also want to force a log switch if the current redo group needs to be archived at a specific time before the members of the group are completely filled.
This option is useful in configurations with large redo log files that take a long time to fill. The status of the current group changes to active and the status of the next group in the list changes from inactive to current. Online redo log files may be moved while the database is shutdown. Although it is possible to indirectly move online redo log files by dropping entire redo log groups and re-adding the groups in a different location, this solution will not work if there are only two redo log groups because a database will not open with only one redo log filegroup.
Temporarily adding a third group and dropping the first or second group is an option if the database must be kept open; alternatively, the method shown here will move the redo log file s while the database is shutdown. In the following example, we have three redo log file groups with two members each. One member of each group is on the same volume as the oracle software and should be moved to a different volume to eliminate any connection between log file filling and accessing oracle software components.
The method you will use here with alter database command. Now, we can check out the location of the log files from the following query. You can configure the database to use checksums to verify blocks in the redo log files.
The checksum is stored in the header of the block. Oracle database uses the checksum to detect corruption in a redo log block. The database verifies the redo log block when the block is read from an archived log during recovery and when it writes the block to an archive log file. An error is raised and written to the alert log if corruption is detected. If corruption is detected in a redo log block while trying to archive it, the system attempts to read the block from another member in the group.
If the block is corrupted in all members of the redo log group, then archiving cannot proceed. Normally we need to clear the redo log if it's corrupted and oracle is not able to reuse it. It may already be archived or may not be.
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. Datafiles should also be placed on different disks from redo log files to reduce contention in writing data blocks and redo records.
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. 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 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:. When the compatibility level is set earlier than Therefore, it is important to consider this limit before creating a database. When compatibility is set to Oracle Database Backup and Recovery Advanced User's Guide to learn how checkpoints and the redo log impact instance recovery. You can force all enabled redo log threads to switch their current logs at regular time intervals.
The changes that are being applied by the standby database can lag behind the changes that are occurring on the primary database, because the standby database must wait for the changes in the primary database redo log to be archived into the archived redo log and then shipped to it. Setting this parameter lets you specify in seconds how long that lag can be. If the following conditions are met, then the instance will switch the log:.
In an Oracle Real Application Clusters environment, the instance also causes other threads to switch and archive their logs if they are falling behind. It also provides an upper limit of how long in seconds the current log of the primary database can span.
Because the estimated archival time is also considered, this is not the exact log switch time. The following initialization parameter setting sets the log switch interval to 30 minutes a typical value. However, in the case of irregularities of redo generation speed, the interval does provide an upper limit for the time range each current log covers. This can force frequent log switches.
Set the parameter to a reasonable value so as not to degrade the performance of the primary database. Plan the redo log of a database and create all required groups and members of redo log files during database creation.
However, there are situations where you might want to create additional groups or members. For example, adding groups to a redo log can correct redo log group availability problems. Using group numbers can make administering redo log groups easier. Do not skip redo log file group numbers that is, do not number your groups 10, 20, 30, and so on , or you will consume unnecessary space in the control files of the database.
In some cases, it might not be necessary to create a complete group of redo log files. A group could already exist, but not be complete because one or more members of the group were dropped for example, because of a disk failure. In this case, you can add new members to an existing group. The following statement adds a new redo log member to redo log group number Notice that filenames must be specified, but sizes need not be.
The size of the new members is determined from the size of the existing members of the group. This procedure is necessary, for example, if the disk currently used for some redo log files is going to be removed, or if datafiles and a number of redo log files are stored on the same disk and should be separated to reduce contention.
Additionally, you might also need operating system privileges to copy files to the desired location and privileges to open and back up the database. Before relocating your redo logs, or making any other structural changes to the database, completely back up the database in case you experience problems while performing the operation. As a precaution, after renaming or relocating a set of redo log files, immediately back up the database control file.
Use the following steps for relocating redo logs. The example used to illustrate these steps assumes:. The redo log files located on diska must be relocated to diskc. Operating system files, such as redo log members, must be copied using the appropriate operating system commands. See your operating system specific documentation for more information about copying files. The following example uses operating system commands UNIX to move the redo log members to a new location:.
In some cases, you may want to drop an entire group of redo log members. For example, you want to reduce the number of groups in an instance redo log. In a different case, you may want to drop one or more specific redo log members. For example, if a disk failure occurs, you may need to drop all the redo log files on the failed disk so that the database does not try to write to the inaccessible files.
In other situations, particular redo log files become unnecessary. For example, a file might be stored in an inappropriate location. Before dropping a redo log group, consider the following restrictions and precautions:.
An instance requires at least two groups of redo log files, regardless of the number of members in the groups. A group comprises one or more members. You can drop a redo log group only if it is inactive. If you need to drop the current group, first force a log switch to occur. Make sure a redo log group is archived if archiving is enabled before dropping it.
When a redo log group is dropped from the database, and you are not using the Oracle-managed files feature, the operating system files are not deleted from disk. Rather, the control files of the associated database are updated to drop the members of the group from the database structure. After dropping a redo log group, make sure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log files.
When using Oracle-managed files, the cleanup of operating systems files is done automatically for you. Consider the following restrictions and precautions before dropping individual redo log members:. It is permissible to drop redo log files so that a multiplexed redo log becomes temporarily asymmetric. For example, if you use duplexed groups of redo log files, you can drop one member of one group, even though all other groups have two members each.
However, you should rectify this situation immediately so that all groups have at least two members, and thereby eliminate the single point of failure possible for the redo log.
An instance always requires at least two valid groups of redo log files, regardless of the number of members in the groups. If the member you want to drop is the last valid member of the group, you cannot drop the member until the other members become valid.
0コメント