Oracle SQL Plus The Definitive Guide- P38 ppsx

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

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

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

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

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

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

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;

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

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

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

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