Oracle RMAN 11g Backup and Recovery (15 page)

During normal database operations, Oracle will open an available online redo log, write redo to it, and then close it once it has filled the online redo log. Once the online redo log has filled, the LGWR process switches to another online redo log group. At that time, if the database is in ARCHIVELOG mode, LGWR also signals ARCH to wake up and start working. This round-robin style of writing to online redo logs is shown in Figure 1-1.

ARCH responds to the call from LGWR by making copies of the online redo log in the locations defined by the Oracle database parameter LOG_ARCHIVE_DEST_
n
and/or to the defined flash recovery area. Until the ARCH process has successfully completed the creation of at least one archived redo log, then the related online redo log file cannot be reused by Oracle. Depending

Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
19

FIGURE 1-1
Writing to online redo logs

on your system configuration, more than one archived redo log may need to be created before the associated online redo log can be reused. As archived redo logs are created, they maintain the log sequence number assigned to the parent online redo log. That log sequence number will remain unique for that database until the database is opened using the
resetlogs
operation. Once a
resetlogs
operation is executed, then the log sequence number is reset to 1.

One final note about opening the database using the
resetlogs
command when performing recovery. If you are using Oracle Database 10
g
and later Oracle provides the ability to restore the database using a backup taken before the point in time that you issued the
resetlogs
command, when you issue the
resetlogs
command, Oracle will archive any remaining unarchived online redo logs, before the online redo logs are reset. This provides the ability to restore the database from a backup taken before the issuance of the
resetlogs
command. Using these backup files, and all the archived redo logs, you can now restore beyond the point of the
resetlogs
command. The ability to restore past the point of the
resetlogs
command relieves the DBA from the urgency of performing a backup after a
resetlogs
-based recovery (though such a backup is still important).

This also provides for reduced mean-time-to-recover, as you can open the database to users after the restore, rather than having a requirement to back up the database first.

Management of Online Redo Logs

The
alter database
command is used to add or remove online redo logs. In this example, we are adding a new online redo log group to the database. The new logfile group will be group 4, and we define its size as 100m:

alter database add logfile group 4

'C:\ORACLE\ORADATA\BETA1\REDO04.LOG' size 100m;

20
Part I: Getting Started with RMAN in Oracle Database 11
g
You can see the resulting logfile group in the V$LOG and V$LOGFILE views: SQL> select group#, sequence#, bytes, members from v$log

2 where group# 4;

GROUP# SEQUENCE# BYTES MEMBERS

---------- ---------- ---------- ----------

4 0 104,857,600 1

SQL> select group#, member from v$logfile

2 where group# 4;

GROUP# MEMBER

---------- -------------------------------------------------------------

4 C:\ORACLE\ORADATA\BETA1\REDO04.LOG

In this next example, we remove redo log file group 4 from the database. Note that this does not physically remove the physical files. You will still have to perform this function after removing the log file group. This can be dangerous, so be careful when doing so:

alter database drop logfile group 4;

NOTE

If you are using the FRA or have set the DB_CREATE_ONLINE_LOG_

DEST_
n
, then Oracle will remove online redo logs for you after you
drop them.

To resize a logfile group, you will need to drop and then re-create it with the bigger file size.

ARCHIVELOG Mode vs. NOARCHIVELOG Mode

An Oracle database can run in one of two modes. By default, the database is created in NOARCHIVELOG mode. This mode permits normal database operations, but does not provide the capability to perform point-in-time recovery operations or online backups. If you want to do online (or hot) backups, then run the database in ARCHIVELOG mode. In ARCHIVELOG mode, the database makes copies of all online redo logs via the ARCH process, to one or more archive log destination directories.

The use of ARCHIVELOG mode requires some configuration of the database beyond simply putting it in ARCHIVELOG mode. You must also configure the ARCH process and prepare the archived redo log destination directories. Note that once an Oracle database is in ARCHIVELOG

mode, that database activity will be suspended once all available online redo logs have been used. The database will remain suspended until those online redo logs have been archived. Thus, incorrect configuration of the database when it is in ARCHIVELOG mode can eventually lead to the database suspending operations because it cannot archive the current online redo logs. This might sound menacing, but really it just boils down to a few basic things:

■ Configure your database properly (we cover configuration of your database for backup and recovery in this book quite well).

■ Make sure you have enough space available.

Chapter 1: Oracle Database 11
g
Backup and Recovery Architecture Tour
21

■ Make sure that things are working as you expect them to. For example, if you define a flash recovery area in your ARCHIVELOG mode database, make sure the archived redo logs are being successfully written to that directory.

More coverage on the implications of ARCHIVELOG mode, how to implement it (and disable it), and configuration for ARCHIVELOG operations can be found in Chapter 3.

Oracle Logical Structures

There are several different logical structures within Oracle. These structures include tables, indexes, views, clusters, user-defined objects, and other objects within the database. Schemas own these objects, and if storage is required for the objects, that storage is allocated from a tablespace.

It is the ultimate goal of an Oracle backup and recovery strategy to be able to recover these logical structures to a given point in time. Also, it is important to recover the data in these different objects in such a way that the state of the data is consistent to a given point in time.

Consider the impact, for example, if you were to recover a table as it looked at 10 A.M., but only recover its associated index as it looked at 9 A.M. The impact of such an inconsistent recovery could be awful. It is this idea of a consistent recovery that really drives Oracle’s backup and recovery mechanism, and RMAN fits nicely into this backup and recovery architectural framework.

The Combined Picture

Now that we have introduced you to the various components of the Oracle database, let’s quickly put together a couple of narratives that demonstrate how they all work together. First, we look at the overall database startup process, which is followed by a narrative of the basic operational use of the database.

Startup and Shutdown of the Database

Our DBA, Eliza, has just finished some work on the database, and it’s time to restart it. She starts SQL*Plus and connects as SYS using the SYSDBA account. At the SQL prompt, Eliza issues the
startup
command to open the database. The following shows an example of the results of this command:

SQL> startup

ORACLE instance started.

Total System Global Area 84700976 bytes

Fixed Size 282416 bytes

Variable Size 71303168 bytes

Database Buffers 12582912 bytes

Redo Buffers 532480 bytes

Database mounted.

Database opened.

Recall the different phases that occur after the
startup
command is issued: instance startup, database mount, and then database open. Let’s look at each of these stages now in a bit more detail.