0526-0528
Page 526
Mirrored Online Redo Logs
In an attempt to preserve the data within the online redo logs in much the same way as control files, Oracle7 introduces redo log groups. They enable redo logs to be mirrored across multiple disks. (See Figure 22.6.)
Figure 22.6.
Mirrored online redo
logs.
Instead of having individual redo logs, each of which contains a distinct series of transactions, the redo logs are broken down into groups and members . Each group is a set of one or more redo logs that contain the same transactions. Each member is a single redo log file within the group . The Oracle RDBMS treats all the redo logs as groups even if they contain only a single member.
You can think of redo log groups as a single redo log. There are at least two redo log groups in a database instance. Each group contains multiple members ”the redo log file ”which should be located on separate physical disks to benefit from the mirroring. As the Oracle RDBMS writes information to the redo log, it writes the information into each member of the group. In this way, if a single member is damaged, at least one of the other members will enable the database to continue to function. This greatly reduces the number of database failures caused by problems with redo logs.
| NOTE |
There is no requirement that each redo log group contains the same number of members. Each group is treated independently of the other groups. |
Page 527
Adding Redo Log Groups
The initial online redo log groups are created at the time of database creation. However, any number of factors can come into play that might prompt the DBA to want to add additional logfile groups. Adding a group of redo log members to the database is done by issuing the alter database command from within Oracle Server*Manager or SQL*Plus. For example,
alter database add logfile group 4 (`/u02/oradata/norm/redo4a.log', `/u03/oradata/norm/redo4b.log') size 512K;
This command causes the database to create a new logfile group (group 4), which assumes that groups 1, 2, and 3 already exist and that group 4 does not. The two members of this group are 512KB files named redo4a.log and redo4b.log, which are located in /u02/oradata/norm and /u03/oradata/norm.
Adding Members to Redo Log Groups
A DBA who is not familiar with Oracle7 might have created online redo logs without mirroring the members. It would benefit him to mirror the redo logs by adding additional members to existing redo log groups. The command syntax for this is
alter database add logfile member `/u04/oradata/norm/redo2b.log' to group 2;
This causes a logfile member named redo2b.log to be placed in the /u04/oradata/norm directory path and to be annotated as a member of redo log group 2. The new logfile member has the same size as the existing logfile members in the group to which it is added.
Renaming or Moving Members
A DBA might experience the situation in which a disk drive needs to be removed because it keeps encountering errors. Perhaps a new disk drive has been added to the system, and some of the redo log members need to be placed on the drive. Whatever the case, redo log members can be quickly renamed or moved by using alter database from within Oracle Server*Manager or SQL*Plus.
To move the file physically from one location to another, specify the name of the file to move and its destination. In the following example, redo1a.log is moved from its present location, /u03/oradata/norm, to its new location, /u06/oradata/norm:
alter database rename file `/u03/oradata/norm/redo1a.log' to `/u06/oradata/norm/redo1a.log';
The same syntax is used to rename a file. Instead of specifying a new path, you specify a new filename. In the following example, redo2a.log in /u03/oradata/norm is renamed to redo3a.log. The directory path is the same.
alter database rename file `/u03/oradata/norm/redo2a.log' to `/u03/oradata/norm/redo3a.log';
Page 528
Dropping Redo Log Groups
To remove an entire group of redo log members, simply remove the group itself. After you remove the group, all the corresponding redo log members are dropped. To do this, issue the alter database command from within Oracle Server*Manager or SQL*Plus. The following code removes all the redo log members for redo log group 5, but it does not affect any other groups:
alter database drop logfile group 5;
Dropping Members from Redo Log Groups
If redo log files are corrupted or if you must conserve disk space, you might have to remove redo log members from a redo log group. To do this, issue the following alter database command from within Oracle Server*Manager or SQL*Plus:
alter database drop logfile member `/u07/oradata/norm/redo6a.log';
This command removes the specified redo log member from its associated redo log group. It does not affect the group or any other redo members.
| NOTE |
The information presented here is only for quick reference. For a more detailed discussion on adding, renaming, or removing redo log groups and members ”and the restrictions associated with these tasks ” consult the Oracle7 Server Administrator's Guide. |
Cold Backups
One of the simplest backup methods , but also one of the most difficult to implement, is the cold backup, also known as the consistent backup. In a cold backup, the database has been closed, but preferably totally shut down, and all the physical files associated with the database are copied by means of normal operating system utilities. Because the database is not in operation, changes are not made to the physical files, and there are no conflicting integrity or consistency problems.
The difficulties in implementing this type of backup are mostly political, due largely to the amount of time required. Depending on the size of the database and the speed of the copy utility used ”copies to disk are faster than copies to tape ”a cold backup can take anywhere from a few minutes to several hours or even several days. Thus, a cold backup is not always an option.
Many sites supplement weekly or monthly cold backups with other backups on a nightly basis. They think that they have 24/7 operations, when in reality large windows of time are available in the evening for a cold backup. This is, of course, site-specific. It is up to the DBA to evaluate the needs of the user community versus the needs of the operations staff.
EAN: 2147483647
Pages: 391