Oracle SQL Plus The Definitive Guide- P38 ppsx

< previous page page_337 next page >
Page 337
that weren't committed. The end result is the same as if you had done a SHUTDOWN IMMEDIATE.
Looking at Your Database
The SHOW command may be used to review information regarding the current state of your database. Use SHOW SGA
to see the information about the size of your System Global Area, or SGA. With SHOW PARAMETER, you can look at
the current settings for the database initialization parameters. SHOW LOGSOURCE and SHOW AUTORECOVERY
give you information about archive logging and recovery.
Remember that the SHOW command options described in this
chapter are new with release 8.1 of SQL*Plus, which was shipped with
Oracle8i. In previous versions of Oracle, these SHOW commands were
implemented only in Server Manager.
Looking at the SGA
The SHOW SGA command may be used to display information regarding the size of the System Global Area. The SGA
is shared by all Oracle processes and contains the database buffer cache, the redo log buffer, shared SQL statements,
and a number of other items. Here is an example of SHOW SGA being used:
SQL> SHOW SGA
Total System Global Area 5508612 bytes
Fixed Size 45584 bytes
Variable Size 4529140 bytes
Database Buffers 409600 bytes
Redo Buffers 524288 bytes
The values returned by SHOW SGA are as follows:
Total System Global Area
The total maximum size of the SGA.
Fixed Size
This is the minimum size of the SGA, and is the size used when the SGA is first allocated.
Variable Size
This is the amount by which the SGA may expand.

< previous page page_337 next page >

< previous page page_338 next page >
Page 338
Database Buffers
The number of bytes allocated for buffering of data blocks from the data files. Oracle tries to keep the most recently used
data in memory, in case it is needed again.
Redo Buffers
The number of bytes allocated for buffering of redo log data. The log writer (LGWR) process reads these buffers and writes
the information they contain to the redo log files.
For more information about the SGA, the structures within it, and the purpose of each of those structures, see Chapter 7 of
the Oracle8 Concepts manual.
Looking at Initialization Parameters
Each Oracle database has a number of initialization parameters that control its behavior. These parameters control a wide
range of things, such as the number of job queue processes to run, the database block size, the shared pool size, and more.
When an Oracle database starts, the initial settings for these parameters are read from an initialization file. Some of these
parameters may be changed dynamically, while the database is up and running. Others may only be changed while the
instance is shut down. Still others, such as the database block size, may never be changed at all.
The SHOW PARAMETERS command may be used to display the value of one or more selected parameters, or of all
parameters. SHOW PARAMETERS with no arguments will get you a listing of everything, as shown in the following
example:
SQL> SHOW PARAMETERS
NAME TYPE VALUE

07_DICTIONARY_ACCESSIBILITY boolean TRUE
allow_partial_sn_results boolean FALSE
always_anti_join string NESTED_LOOPS
aq_tm_processes integer 0
arch_io_slaves integer 0
audit_trail string NONE
b_tree_bitmap_plans boolean FALSE
background_dump_dest string %RDBMS80%\trace

backup_disk_io_slaves integer 0
backup_tape_io_slaves boolean FALSE
bitmap_merge_area_size integer 1048576
blank_trimming boolean FALSE
buffer_pool_keep string
buffer_pool_recycle string
cache_size_threshold integer 20
cleanup_rollback_entries integer 20

< previous page page_338 next page >
< previous page page_339 next page >
Page 339
You can narrow down the results by using a specific parameter name as an argument, for example:
SQL> SHOW PARAMETERS log_checkpoint_interval
NAME TYPE VALUE

log_checkpoint_interval integer 10000
A useful variation on this theme is that you may specify any string you like as an argument to SHOW PARAMETERS, and
SQL*Plus will display all the parameters whose names contain that string. The following example shows all the LOG
related parameters, plus a few others containing the string LOG:
SVRMGR> SHOW PARAMETERS log
NAME TYPE VALUE

dblink_encrypt_login boolean FALSE
delayed_logging_block_cleanouts boolean TRUE
log_archive_buffer_size integer 127
log_archive_buffers integer 4
log_archive_dest string %RDBMS80%\
log_archive_duplex_dest string
log_archive_format string ARC%s. %t

log_archive_min_succeed_dest integer 1
log_archive_start boolean FALSE
log_block_checksum boolean FALSE
log_buffer integer 8192
log_checkpoint_interval integer 10000
log_checkpoint_timeout integer 0
log_checkpoints_to_alert boolean FALSE
log_file_name_convert string
log_files integer 255
log_simultaneous_copies integer 0
log_small_entry_max_size integer 80
mts_rate_log_size string
remote_login_passwordfile string SHARED
Looking at Archive and Recovery Information
SQL*Plus implements three commands that let you view information about archive logging and recovery. The SHOW
LOGSOURCE command may be used to find out what directory your database's archive log files are being written to.
Here's an example:
SQL> SHOW LOGSOURCE
Logsource G:\INSTANCES\PLUM\LOGS
If you want to see more information about the status of archive logging, use the ARCHIVE LOG LIST command as shown
in this example:
SQL> ARCHIVE LOG LIST
Database log mode Archive Mode

< previous page page_339 next page >
< previous page page_340 next page >
Page 340
Automatic archival Enabled
Archive destination G:\INSTANCES\PLUM\LOGS
Oldest online log sequence 35

Next log sequence to archive 36
Current log sequence 36
The output from ARCHIVE LOG LIST is as follows:
Database log mode
Tells you whether or not your database is running in archive mode. The value will be either Archive Mode or
NOArchive Mode.
Automatic archival
Tells you whether or not redo logs are automatically being archived. If automatic archival is enabled, that means you
have an archiver process (ARCH) running, and your redo logs are automatically being copied to another device as each
one is closed.
Archive destination
Tells you the archive destination. This is the same information you get from the SHOW LOGSOURCE command.
Oldest online log sequence
Tells you the sequence number of the oldest redo log group that hasn't been archived yet. Oracle increments this
sequence each time a log switch occurs.
Next log sequence to archive
Tells you the sequence number of the next group of log files to be archived. If automatic archiving is disabled, this line
won't be displayed. This value will always be less than the current log sequence.
Current log sequence
Tells you the sequence number of the redo log group currently in use.
You can get an idea of how well the archiving process, which is named ARCH, is keeping up by looking at the values
for the next log sequence archive and the current log sequence. A large difference between these two values indicates
that the ARCH process is falling behind. If the archiver falls too far behind, the log writer process won't be able to open
another group, and database users will have to wait for one to be archived. If this happens frequently, you may be able
to resolve the situation by creating more redo log groups, making your existing groups larger, or starting more archive
processes.
Database Backup and Recovery
Beginning with version 8.1, SQL*Plus implements commands to manage the archiving of redo log files and to perform
point-in-time recovery of a database. In order to understand how these commands work, and to place them in their
proper

< previous page page_340 next page >
< previous page page_341 next page >
Page 341
context, you need to understand something of how backup and recovery work in an Oracle environment.
This section explains the two fundamental approaches to backing up an Oracle database, and shows you how SQL*Plus
may fit into your backup process. Archive logging will be explained, and you will see how SQL*Plus can be used to
start, stop, and monitor that process. Finally, you will see how the SQL*Plus RECOVER command can be used to apply
archive logs to a restored database in order to get up-to-the-minute recovery.
If you are responsible for backing up an Oracle database, please do not depend on just this one chapter to show you how
to do that properly. There are several excellent books on the subject. One you should become very familiar with is the
Oracle8 Backup and Recovery Guideit's one of the manuals in the Oracle documentation set. Another book worth
looking at is the Oracle8 Backup and Recovery Handbook, by Rama Velpuri and Anand Adkoli (Oracle Press, 1998). In
addition, Oracle offers the three-day-long Oracle8 Backup and Recovery Workshop.
Of all the things that a database administrator is responsible for,
protecting the data is probably first on the list.
The discussion of backup and recovery in this chapter is very high-level. The recovery scenario used as an example
represents just one of many possibilities. It's a common scenario, and serves well to illustrate the use of the
RECOVERY command, but there are a number of other possible scenarios you have to know how to handle in order to
be confident that you can recover from a disaster.
Backups
There are two fundamental approaches to backing up an Oracle database. The first and easiest approach is to shut down
the database and copy the files to a backup medium such as a tape. This is referred to as making a cold backup, because
the database is closed, or cold, when you make it. Cold backups carry with them one major disadvantageyou must shut
down the database. In a 24x7 shop, this may not be an option.
With cold backups, you have to decide whether or not you need point-in-time recovery in the case of a failure. Enabling
archive log mode gives you the ability to restore a cold backup and then reapply all committed transactions up to the
point in time at which the failure occurred. Archiving is discussed in detail later in

< previous page page_341 next page >

< previous page page_342 next page >
Page 342
this chapter. Cold backups are the easiest to implement, and are often used for small databases.
Oracle provides a second approach to backing up a database that avoids the need for a shutdown. This involves copying
the files while the database is open and being used, and is known as making a hot backup. You must have archive
logging enabled in order to make a hot backup, so point-in-time recovery capabilities are automatically included.
Cold backups
Making a cold backup of your database is a relatively painless process. You simply follow these three steps:
1. Shut down the database normally, so that you have a consistent set of database files. This must be done with the
SHUTDOWN, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL command.
2. Copy all the database files to backup media, such as a tape. This copying can be done manually, or it can be done by
whatever backup software you employ.
3. Restart the database using the STARTUP command.
To restore a database from a cold backup, you shut down the instance, copy the files from the backup media back to
their original locations, then restart the instance. Your database will be restored to the way it was when you first took
the backup.
It is possible, when restoring a database from a cold backup, to place
the datafiles somewhere other than their original locations. This may be
necessary if you have lost a disk drive. If you do this, you will need to use the
ALTER DATABASE RENAME DATAFILE command before opening your
database.
If you aren't sure which files to back up, you can find out by querying the data dictionary. The V$DATAFILE view
returns information about each datafile used by the database, while V$LOGFILE tells you about the redo log files. The
following query will return a list of all data and log files:
SELECT name
FROM v$datafile
UNION
SELECT member
FROM v$logfile;

< previous page page_342 next page >
< previous page page_343 next page >
Page 343
The only other files you need to worry about are the control files and the initialization file. You can get a list of control
files by looking at the CONTROL_FILES entry in the initialization file, or by issuing the following command from
SQL*Plus:
SHOW PARAMETERS control_files
The initialization file is the one used with the PFILE parameter on the STARTUP command. You should know where
this is. Oracle won't keep track of it for you.
Cold backups are often done as part of a nightly backup process that makes a copy of all files on your system. At some
point prior to making the backup, the database is shut down. The backup job then runs, copying all files on the system to
tape. When the backup job is complete, the database is restarted.
Generate a listing of all datafiles, log files, and control files
associated with the database each night. You will need it when it comes time to
restore.
If you are making cold backups as part of a nightly operating-system backup, you probably don't worry too much about
which files are database files, since everything is being backed up anyway. You should worry. Knowing where your
database files are is important when it comes time to restore, and for two reasons. First, if you need to restore your
database, you will need to know which files to pull off the backup tape. You will also need to know where to place
them. Second, you may be restoring the files to a different location, maybe to a different disk. If this is the case, you
will need to issue ALTER DATABASE RENAME DATAFILE commands to tell Oracle the new location of the files.
In order to do that, you will need to supply the old location as well.
Hot backups
Hot backups allow you to back up the database while it is open and being used, avoiding the major disadvantage of the
cold backup approach. Also, with a hot backup, you automatically get point-in-time recovery. In the event of a disk
failure, this allows you to restore the database and recover all transactions up to the time of failure.
Because the files are open when you make a hot backup, they may not be consistent with one another. Consider, for
example, a transaction that affects records stored in different datafiles. It isn't likely that the changes to both datafiles
will be written to disk at exactly the same time. Thus, one datafile could be up-to-date, while changes to the second
datafile could still be buffered in memory. If you take your hot backup at this moment, the two datafiles you copy won't

be consistent in

< previous page page_343 next page >
< previous page page_344 next page >
Page 344
regard to a single point in time. Look at Figure 10-2 to see a simplistic representation of how this works. Assume that
you have just added a new employee to your database and assigned him to a department. Figure 10-2 shows the
database in a state where the employee record has been written to a datafile, but the department record has not.
Figure 10-2.
Databasefiles in an inconsistent state
You can see from Figure 10-2 that the new employee record has been written to a database file. The updated department
record, however, with its count of active employees, still remains buffered in memory. The dotted line in Figure 10-2
shows what you would get if you copied the files at this point in time. In order to restore a database from this type of
backup, Oracle needs to know what changes to make to the department data file in order to bring it up to date with the
rest of the database. Oracle can get this information from the redo logs, but in order to do that you must be saving these
log files somewhere. You do that by running the database in archive log mode, which is described in the section titled
Archiving.
When taking a hot backup, you must use the ALTER
TABLESPACE BEGIN BACKUP and ALTER TABLESPACE END
BACKUP commands before and after copying each tablespace's datafiles. See
the Oracle8 Backup and Recovery Guide for detailed information on performing
a hot backup.
When restoring a database from a hot backup, you first shut down the database, then copy the data files back from tape.
Finally, you go through a process called recovery. Recovery allows you to reapply transactions to the data files,
bringing them up to date so they are consistent with one another and reflect the results of the last successful transaction
prior to the failure. This is known as point-in-time

< previous page page_344 next page >
< previous page page_345 next page >
Page 345

recovery, because you can restore the database to the exact point of time that the failure occurred. See the section titled
Recovery, later in this chapter, for detailed information on the recovery process.
Archiving.
Archiving, in the Oracle world, is the process of saving redo log files for later use in a recovery process. Look at Figure
10-3. It's the same as Figure 10-2, except it also shows the redo log files. Whenever you change data in an Oracle
database, the changes are written to a log file. This write occurs very quickly because it's a sequential writethe data is
just appended to the end of the current log. This writing of the log file can lag somewhat behind your actual changes,
but Oracle always catches up whenever you issue a COMMIT command. Transaction numbers are written with each log
file record, so Oracle can keep track of which changes have been committed and which have not.
Figure 10-3.
Changes written to the redo log files
These redo logs protect the database against a sudden interruption in the running of the software, such as you might get
by kicking the computer's plug out of the wall. When you restart Oracle after a power failure, Oracle will immediately
read through the redo log files to pick up any changes that weren't written to the database files before the crash. The
database files are then updated with these changes, restoring things to the way they should have been had the crash not
occurred. This process is known as crash recovery, and protects the database

< previous page page_345 next page >
< previous page page_346 next page >
Page 346
against any sudden interruptions that do not result in damage to the disks containing the database files.
To enable crash recovery, the logs only need to remain long enough for the same data to be written to the actual data
files. Once that has happened, Oracle will reuse the log file for the next set of changes. In a running database, Oracle
will continually cycle through a set of log files, moving from one to the next to the next as fast as each one is filled with
data, saving only enough information to recover from an instance crash.
It stands to reason that if Oracle can use the log files to recover from an instance crash, it ought to be able to use the
same log files to recover from a disk failure. Indeed it can; the only difference is in the number of log files you need to
keep around. Saving all redo logs since the time of the most recent backup allows you to fully recover the database
when files are lost or damaged. You recover the database by restoring the database files from the backup and reapplying
subsequent changes from the log files.

Not everyone will have enough disk space to keep all redo log files online for a long period of time. This was
particularly true years ago when the cost of the media was relatively high. This is where archiving comes in. Oracle
provides the capability to archive redo log files to tape or some other media as they are being made. This gives you the
scenario shown in Figure 10-4.
In many cases today, people just archive the redo logs to a separate disk, maybe a slower and cheaper disk than the one
used for the redo log files. Whatever the case, running a database in archive log mode is fundamental to any backup
strategy where point-in-time recovery is required.
Turning on archive log mode
The ALTER DATABASE command can be used to put a database into archive log mode. It's important to remember
that archive logs are useless for recovery without a full backup to use as a starting point, so before you turn archive log
mode on, you should take a complete backup of your database. Generally, you should follow these steps:
1. Shut down the instance, closing the database.
2. Take a cold backup of the database.
3. Edit the initialization file. Check to make sure there is a LOG_ARCHIVE_DEST parameter, that it is uncommented,
and that it is pointing to a valid directory.
4. Start the instance and mount, but don't open, the database. Use the STARTUP MOUNT command for this purpose.
5. Turn archive log mode on using the ALTER DATABASE command.

< previous page page_346 next page >