Instance Management


This section helps you develop an approach to managing your database instance or – if you have an Oracle Real Application Cluster (RAC) – your instances.

This section discusses how to approach instance management.

For more information on how to perform instance management, see Database Instance Management with BR*Tools.


The main components of the database and instance are shown in the following graphic:

When an Oracle database is running, it is associated with an instance. The process of associating the database with an instance is called mounting the database. To make the mounted database accessible to authorized users, you must open it.


Starting Up the Database

You can start up the database as follows:


What Happens


No mount

Database instance is built up

Operating system resources are allocated using configuration information stored in the profile init<DBSID>.ora or the spfile.

brspace -f dbstart -s nomount


Database control files are evaluated.

Information about the file structure of the database is read

Data files and logs are not yet opened.

brspace -f dbstart -s mount


All files in the database system are opened.

If required, instance recovery is performed immediately after opening the database.

Pending database transactions are ended.

brspace -f dbstart -s open

If you have an Oracle Real Application Cluster (RAC), you can start up all instances that are currently down with the all_down parameter:

brspace -f -i all_down

Shutting Down the Database

You can shut down the database as follows:


What Happens



No new database logon possible.

After all database user have logged off, the database is closed properly: all files are closed, the database is dismounted, and the instance is shut down.

The database is consistent after shutdown.

brspace -f dbshut -m normal


Only the current commands are executed.

PMON ends all sessions and performs a rollback of the open transactions.

The database is then closed properly (as for a normal shutdown). The database is consistent after shutdown.

DBWR and ARCH might require up to 1 hour post-processing time.

brspace -f dbshut -m immediate


No new connections are allowed and no new transactions can be started.

Oracle waits for all open transactions to finish, then disconnects all users (that is, work processes in the SAP system) and shuts down the database

brspace -f dbshut -m transactional


Emergency database shutdown

Users are not logged off and open transactions are not rolled back.

The database is not consistent after shutdown.

An instance recovery is automatically performed at the next database startup.

brspace -f dbshut -m abort

If you have an Oracle Real Application Cluster (RAC), you can shut down all instances that are currently up with the all_up parameter:

brspace -f dbshut –i all_up

Altering the Database Instance

You can alter the database instance as follows:

·        Switch the current online redo log file

You might want to do this when, for example, you want to apply the data changes immediately to a standby database.

·        Force a database checkpoint

You might want to do this when, for example, you want to shorten the database shutdown time after the checkpoint.

For more information, see the Oracle documentation.

·        Set archivelog mode

When you set up the database, you normally make sure that you set archivelog mode on.

·        Set noarchivelog mode

You can set noarchivelog mode on for short periods to perform essential database administration. The advantages are:

Ў        You save space in the archive directory

Ў        There is a performance gain

It is very important that your database normally runs with archivelog mode set and with automatic archiving enabled. This makes sure that the online redo log files, which contain a record of the database transactions, are backed up. This means that you can recover the database in the event of a failure involving data loss.

For more information on Set archivelog mode and Set noarchivelog mode, see Setting Up Archiving.

Altering Database Parameters

You can alter database parameters in the following profiles:

·        init<DBSID>.ora file, which is a normal disk file. It is still used by many SAP transactions, so must be kept up-to-date with the newer spfile (see below).

·        spfile, which is a new binary server-side parameter file introduced by Oracle, available as part of the standard installation from SAP Web AS 6.40. If your SAP system was upgraded from an older release, you have to create it yourself initially using SQL*Plus because it was not part of older SAP installations.

We recommend that you always use BR*Tools to alter database parameters, because BRSPACE ensures that the two files are synchronized whenever you make a change. Do not change either file manually at operating system level.

You can change parameters with the following scope:


Where the Change Occurs

When the Change Occurs



Memory of the currently running instance

Immediately, but does not persist when database is restarted

Immediate but not persistent


spfile and init<DBSID>.ora

At next database startup and persists from then on

Persistent but not immediate


spfile and init<DBSID>.ora and memory of the currently running instance

Immediately and persists through subsequent database startups

Immediate and persistent

When you perform parameter changes with BRSPACE, it maintains a history of all changes in the BRSPACE Parameter Change Log.

The name of the Oracle spfile on single database installations is spfile<DBSID>.ora and on RAC installations spfile.

Recreating the Database

For more information, see Recreate Database.