SAP BASIS Administration

(Oracle Brtools Exercise)

1)SHOW SGA;
Total System Global Area 36437964 bytes
Fixed Size 6543794 bytes
Variable Size 19521536 bytes
Database Buffers 16777216 bytes
Redo Buffers 73728 bytes

2) ALTER SYSTEM SET DB_CACHE_SIZE = 96M;

Database buffer cache can be dynamically resized

to grow or shrink using ALTER SYSTEM.
• DB_CACHE_ADVICE can be set to gather statistics
for predicting different cache size behavior.

3) Redo Log Buffer Cache

The redo log buffer cache records all changes
made to the database data blocks.
• Its primary purpose is recovery.
• Changes recorded within are called redo entries.
• Redo entries contain information to reconstruct
or redo changes.
• Size is defined by
LOG_BUFFER.
Redo log
buffer cache

Redo Log Buffer Cache

The redo log buffer cache is a circular buffer that contains changes made to data file
blocks.
This information is stored in redo entries. Redo entries contain the information necessary
to
recreate the data prior to the change made by INSERT, UPDATE, DELETE, CREATE,
ALTER, or DROP operations.
Sizing the Redo Log Buffer Cache
SAP BASIS Administration
(Oracle Brtools Exercise)

The size of the redo log buffer cache is defined by the initialization parameter
LOG_BUFFER.

5) Database Writer (DBWn)

DBWn writes when:
• Checkpoint
• Dirty buffers threshold
reached
• No free buffers
• Timeout
• RAC ping request
• Tablespace offline
• Tablespace read only
• Table DROP or
TRUNCATE
• Tablespace BEGIN

5) Log Writer (LGWR)

LGWR writes:
• At commit
• When one-third full
• When there is 1 MB
of redo
• Every 3 seconds
• Before DBWn
writes

6) System Monitor (SMON)

Responsibilities:
• Instance recovery:
– Rolls forward
changes in the
redo logs
– Opens the
database for
user access
SAP BASIS Administration
(Oracle Brtools Exercise)

– Rolls back
uncommitted
transactions
• Coalesces free
space ever 3 sec
• Deallocates
temporary segments

System Monitor
If the Oracle instance fails, any information in the SGA that has not been written to disk
is
lost. For example, the failure of the operating system causes an instance failure. After the
loss
of the instance, the background process SMON automatically performs instance recovery
when the database is reopened. Instance recovery consists of the following steps:
1. Rolling forward to recover data that has not been recorded in the data files but that has
been recorded in the online redo log. This data has not been written to disk because of
the loss of the SGA during instance failure. During this process, SMON reads the redo
log files and applies the changes recorded in the redo log to the data blocks. Because all
committed transactions have been written to the redo logs, this process completely
recovers these transactions.
2. Opening the database so that users can log on. Any data that is not locked by
unrecovered transactions is immediately available.
3. Rolling back uncommitted transactions. They are rolled back by SMON or by the
individual server processes as they access locked data.
SMON also performs some space maintenance functions:
• It combines, or coalesces, adjacent areas of free space in the data files.
• It deallocates temporary segments to return them as free space in data files. Temporary
segments are used to store data during SQL statement processing.

Process Monitor (PMON)

Cleans up after
failed processes by:
• Rolling back the
transaction
• Releasing locks
• Releasing other
resources
• Restarts dead
PGA area dispatchers
SAP BASIS Administration
(Oracle Brtools Exercise)

Process Monitor
The background process PMON cleans up after failed processes by:
• Rolling back the user’s current transaction
• Releasing all currently held table or row locks
• Freeing other resources currently reserved by the user
• Restarts dead dispatchers

8) Responsible for:
• Signalling DBWn
at checkpoints
• Updating datafile
headers with
checkpoint
information
• Updating control
files with
checkpoint
information

The Archiver Process

All other background processes are optional, depending on the configuration of the
database;
however, one of them, ARCn, is crucial to recovering a database after the loss of a disk.
As
online redo log files fill, the Oracle server begins writing to the next online redo log file.
The
process of switching from one redo log to another is called a log switch. The ARCn
process
initiates backing up, or archiving, of the filled log group at every log switch. It
automatically
archives the online redo log before the log can be reused, so that all of the changes made
to
the database are preserved. This enables the DBA to recover the database to the point of
failure, even if a disk drive is damaged.
Archiving Redo Log Files
One of the important decisions that a DBA has to make is whether to configure the
database
to operate in ARCHIVELOG or in NOARCHIVELOG mode.
NOARCHIVELOG Mode: In NOARCHIVELOG mode, the online redo log files are
SAP BASIS Administration
(Oracle Brtools Exercise)

overwritten each time a log switch occurs. LGWR does not overwrite a redo log group
until
the checkpoint for that group is complete. This ensures that committed data can be
recovered
if there is an instance crash. During the instance crash, only the SGA is lost. There is no
loss
of disks, only memory. For example, an operating system crash causes an instance crash.
1-35 Copyright © Oracle Corporation, 2001. All rights reserved.

Archiver (ARCn)
• Optional background process
• Automatically archives online redo logs when
ARCHIVELOG mode is set
• Preserves the record of all changes made to the
database
Control
files
Data
files
Redo log
files
Archived
Redo log
files
ARCn
DBA Fundamentals I 1-36
Archiving Redo Log Files (continued)
ARCHIVELOG Mode: If the database is configured to run in ARCHIVELOG mode,
inactive
groups of filled online redo log files must be archived before they can be used again.
Since
changes made to the database are recorded in the online redo log files, the database
administrator can use the physical backup of the data files and the archived online redo
log
files to recover the database without losing any committed data because of any single
point of
failure, including the loss of a disk. Usually, a production database is configured to run in
ARCHIVELOG mode.
Archive log modes are covered in further detail in the DBA Fundamentals

9)
SYSTEM are created automatically and granted the
DBA role.
SYS
• Password:
SAP BASIS Administration
(Oracle Brtools Exercise)

change_on_install
• Owner of the database
data dictionary
SYSTEM
• Password:
manager
• Owner of additional
internal tables and
views used by Oracle
tools

The Database Administrator Users

Extra privileges are necessary to execute administrative duties on the Oracle server, such
as
creating users. Two database user accounts, SYS and SYSTEM, are created automatically
with the database and granted the DBA role. That is, a predefined role that is created
automatically with every database. The DBA role has all database system privileges.
SYS
When a database is created, the user SYS, identified initially by the password
change_on_install, is created. SYS owns the vitally important data dictionary.
SYSTEM
When a database is created, the user SYSTEM, identified initially by the password
manager,
is also created automatically. Additional tables and views owned by the user SYSTEM
are
created. They contain administrative information used by Oracle tools.
Additional users may be created depending on the mode of database creation i.e.,
manually,
or using Database Creation Assistant. You will want to create at least one additional
administrator username to use when performing daily administrative tasks.
For security reasons, the default passwords of SYS and SYSTEM should be changed
immediately after database creation

10) Using Password File Authentication

• Create the password file using the password
utility:
$orapwd file=$ORACLE_HOME/dbs/orapwU15
password=admin entries=5
GRANT SYSDBA TO HR;
• Set REMOTE_LOGIN_PASSWORDFILE to EXCLUSIVE
SAP BASIS Administration
(Oracle Brtools Exercise)

in the initialization parameter file

• Add users to the password file and assign
appropriate privileges to each user
How

Starting Up a Database
When starting the database, you select the state in which it starts. The following scenarios
describe different stages of starting up an instance.
Starting the Instance (NOMOUNT)
Usually you would start an instance without mounting a database only during database
creation or the re-creation of control files.
Starting an instance includes the following tasks:
• Reading the initialization file from $ORACLE_HOME/dbs in the following order:
– First spfileSID.ora. If not found then
– spfile.ora
– initSID.ora
• Specifying the PFILE parameter with STARTUP overrides the default behavior
• Allocating the SGA
• Starting the background processes
• Opening the alertSID.log file and the trace files
The database must be named with the DB_NAME parameter either in the initialization
file or
SAP BASIS Administration
(Oracle Brtools Exercise)

in the STARTUP command.

Starting Up a Database
Mounting the Database To perform specific maintenance operations, you start an
instance
and mount a database but do not open the database.
For example, the database must be mounted but not open during the following tasks:
• Renaming data files
• Enabling and disabling redo log archiving options
• Performing full database recovery
Mounting a database includes the following tasks:
• Associating a database with a previously started instance
• Locating and opening the control files specified in the parameter file
• Reading the control files to obtain the names and status of the datafiles and redo log
files. (However, no checks are performed to verify the existence of the data files and
online redo log files at this time.)
SAP BASIS Administration
(Oracle Brtools Exercise)

Starting Up a Database
Opening the Database Normal database operation means that an instance is started and
the
database is mounted and open; with normal database operation, any valid user can
connect to
the database and perform typical data access operations.
Opening the database includes the following tasks:
• Opening the online data files
• Opening the online redo log files
If any of the data files or online redo log files are not present when you attempt to open
the
database, the Oracle server returns an error.
During this final stage, the Oracle server verifies that all the data files and online redo log
files can be opened and checks the consistency of the database. If necessary, the System
Monitor background process (SMON) initiates instance recovery

STARTUP Command
STARTUP
Start up the instance and open the database:
STARTUP PFILE=$ORACLE_HOME/dbs/initdb01.ora
SAP BASIS Administration
(Oracle Brtools Exercise)

Starting Up
To start up an instance, use the following command:
STARTUP [FORCE] [RESTRICT] [PFILE=filename]
[OPEN [RECOVER][database]
|MOUNT
|NOMOUNT]

Changing the Status of the Database

To open the database from STARTUP NOMOUNT to a MOUNT stage or from MOUNT
to an
OPEN stage, use the ALTER DATABASE command:
ALTER DATABASE { MOUNT | OPEN }

12)

Shutting Down the Database

Shut down the database to make operating system offline backups of all physical
structures and
to have modified static initialization parameters take effect.
To shut down an instance you must connect as SYSOPER or SYSDBA and use the
following
command:
SHUTDOWN [NORMAL | TRANSACTIONAL | IMMEDIATE | ABORT ]
SAP BASIS Administration
(Oracle Brtools Exercise)
SAP BASIS Administration
(Oracle Brtools Exercise)

Shutdown Options
Shutdown Normal
Normal is the default shutdown mode. Normal database shutdown proceeds with the
following conditions:
• No new connections can be made.
• The Oracle server waits for all users to disconnect before completing the shutdown.
• Database and redo buffers are written to disk.
• Background processes are terminated, and the SGA is removed from memory.
• Oracle closes and dismounts the database before shutting down the instance.
• The next startup does not require an instance recovery.
Shutdown Transactional
A transactional shutdown prevents clients from losing work. A transactional database
shutdown proceeds with the following conditions:
• No client can start a new transaction on this particular instance.
• A client is disconnected when the client ends the transaction that is in progress.
• When all transactions have finished, a shutdown immediately occurs.
• The next startup does not require an instance recovery.
DBA
Shutdown Options (continued)
Shutdown Immediate
Immediate database shutdown proceeds with the following conditions:
SAP BASIS Administration
(Oracle Brtools Exercise)

• Current SQL statements being processed by Oracle are not completed.

• The Oracle server does not wait for users currently connected to the database to
disconnect.
• Oracle rolls back active transactions and disconnects all connected users.
• Oracle closes and dismounts the database before shutting down the instance.
• The next startup does not require an instance recovery.

Shutdown Options
Shutdown Abort
If the normal and immediate shutdown options do not work, you can abort the current
database instance. Aborting an instance proceeds with the following conditions:
• Current SQL statements being processed by the Oracle server are immediately
terminated.
• Oracle does not wait for users currently connected to the database to disconnect.
• Database and redo buffers are not written to disk.
• Uncommitted transactions are not rolled back.
• The instance is terminated without closing the files.
• The database is not closed or dismounted.
• The next startup requires instance recovery, which occurs automatically

13) Alert Log File

SAP BASIS Administration
(Oracle Brtools Exercise)

Each Oracle instance has an alert log file. If not already created, Oracle creates one
during
instance startup. The alert log file is managed by you, as it continues to grow while the
database continues to work. The alert log file should be the first place you look when
diagnosing day-to-day operations or errors. The alert log file also contains pointers to
trace
files for more detailed information.
The alert log file keeps a record of the following information:
• When the database was started or shut down.
• A list of all non-default initialization parameters
• The startup of background processes
• The thread being used by the instance
• The log sequence number LGWR is writing to
• Information regarding a log switch
• Creation of tablespaces and undo segments
• Alter statements that have been issued
• Information regarding error messages such as ORA-600 and extent errors

Alert Log File (continued)

The alert_SID.log location is defined by the BACKGROUND_DUMP_DEST
initialization
parameter. The default location on Unix is $ORACLE_HOME/rdbms/log.

Background Trace Files

Background trace files are used to log errors that have been encountered by a background
process, such are SMON, PMON, DBWn, and other background processes. These files
exist
only when an error requires writing to the trace files. You use these files to diagnose and
troubleshoot problems. Initially when a background trace file is created it contains header
information indicating the version number of the data server and the operating system.
Naming convention for background trace files: sid_processname_PID.trc
(db01_lgwr_23845.trc) on Unix. Its location is defined by the
BACKGROUND_DUMP_DEST initialization parameter. The default location on Unix is
$ORACLE_HOME/rdbms/log.

User Trace Files

User trace files contain statistics for traced SQL statements, which are useful for SQL
tuning.
In addition, user trace files contain user error messages.
Naming convention for user trace file: sid_ora_PID.trc (db01_ora_23845.trc) on
Unix. Its location is defined by the USER_DUMP_DEST initialization parameter. The
default
SAP BASIS Administration
(Oracle Brtools Exercise)

location on Unix is $ORACLE_HOME/rdbms/log.

User tracing is enabled or disabled at the session or

instance level by using the following commands and
parameter:
• Session level using the ALTER SESSION command:
ALTER SESSION SET SQL_TRACE = TRUE
• Session level by executing DBMS procedure:
dbms_system.SET_SQL_TRACE_IN_SESSION
• Instance level by setting the initialization
parameter:
SQL_TRACE = TRUE

Backup After Database Structure Changes

Because the control file records the physical structure of the database, you should
immediately make a backup of your control file after making changes to the physical
structure of the database.
SAP BASIS Administration
(Oracle Brtools Exercise)

You can create a backup of a control file, but you cannot bring a control file back from a
backup without its appropriate data files. The control file is a living file that corresponds
to
current database status.
ALTER DATABASE BACKUP CONTROLFILE TO 'FILENAME'
You can also backup your control file to a trace file. This will create a file with the SQL
statements required to recreate your control file.
ALTER DATABASE BACKUP CONTROLFILE TO TRACE
Backup and recovery of the control file is covered in detail in the course

Control file names are uniquely generated and

displayed in the alertSID.log file when the files
are created

The SHOW PARAMETERS command can also be used to find the location of the
control files.
show parameters control_files;
NAME TYPE VALUE
------------ ------- ------------------------------
control_files string /u01/home/db03/ORADATA/u01/ctrl01.ctl
Information in several of the other dynamic performance

Structure of the Redo Log Files

The database administrator can set up the Oracle database to maintain copies of online
redo
log files to avoid losing database information due to a single point of failure.
Online Redo Log Groups
• A set of identical copies of online redo log files is called an online redo log group.
• The LGWR background process concurrently writes the same information to all online
redo log files in a group.
• The Oracle server needs a minimum of two online redo log file groups for the normal
operation of a database.
Online Redo Log Members
• Each online redo log file in a group is called a member.
• Each member in a group has identical log sequence numbers and the same size. The log
sequence number is assigned each time the Oracle server starts writing to a log group to
identify each redo log file uniquely. The current log sequence number is stored in the
control file and in the header of all data files.

How Redo Logs Work

The Oracle server sequentially records all changes made to the database in the redo log
buffer. The redo entries are written from the redo log buffer to one of the online redo log
SAP BASIS Administration
(Oracle Brtools Exercise)

groups called the current online redo log group by the LGWR process. LGWR writes
under
the following situations:
• When a transaction commits
• When the redo log buffer becomes one-third full
• When there is more than a megabyte of changed records in the redo log buffer
• Before the DBWn writes modified blocks in the database buffer cache to the data files
Redo logs are used in a cyclic fashion. Each redo log file group is identified by a log
sequence number that is overwritten each time the log is reused.
Log Switches
LGWR writes to the online redo log files sequentially. When the current online redo log
group is filled, LGWR begins writing to the next group. This is called a log switch.
When the last available online redo log file is filled, LGWR returns

14) The checkpoint background process CKPT updates the headers of all data files and
control files to reflect that it has completed successfully.
Checkpoints can occur for all data files in the database or for only specific data files.
A checkpoint occurs, for example, in the following situations:
• At every log switch
• When an instance has been shut down with the normal, transactional, or immediate
option
• When forced by setting the initialization parameter FAST_START_MTTR_TARGET.
• When manually requested by the database administrator
• When the ALTER TABLESPACE [OFFLINE NORMAL|READ ONLY|BEGIN
BACKUP] cause checkpointing on specific data files.
Information about each checkpoint is recorded in the alert_SID.log file if the
LOG_CHECKPOINTS_TO_ALERT initialization parameter is set to TRUE. The default
value
of FALSE for this parameter does not log checkpoints.
SAP BASIS Administration
(Oracle Brtools Exercise)

Forcing Log Switches and Checkpoints

Log switches and checkpoints are automatically done at certain points in the operation of
the
database as identified previously, but a DBA can force a log switch or a checkpoint to
occur.
Forcing Log Switches
A log switch can be forced using the following SQL command:
ALTER SYSTEM SWITCH LOGFILE;
Forcing Checkpoints
A checkpoint can be forced using the following SQL command:
ALTER SYSTEM CHECKPOINT;
A checkpoint can be forced using the FAST_START_MTTR_TARGET parameter.
FAST_START_MTTR_TARGET is a shortcut to the deprecated parameters
FAST_START_IO_TARGET and LOG_CHECKPOINT_TIMEOUT.
FAST_START_MTTR_TARGET = 600 indicates that instance recovery should not take
more than 600 seconds, and the database will adjust the other parameters to this goal.
FAST_START_IO_TARGET and LOG_CHECKPOINT_TIMEOUT must not be used if
FAST_START_MTTR_TARGET is used.
SAP BASIS Administration
(Oracle Brtools Exercise)

Information about group and members can be

obtained by querying the data dictionary.
• V$LOG
• V$LOGFILE
Obtaining Log Group and Member Information
V$LOG
The following query returns information about the online redo log file from the control
file:
SQL> SELECT group#, sequence#, bytes, members, status
2 FROM v$log;
GROUP# SEQUENCE# BYTES MEMBERS STATUS
--------- ---------- -------- --------- ---------
1 688 1048576 1 CURRENT
2 689 1048576 1 INACTIVE
2 rows selected.
The following items are the most common values for the STATUS column

Archived Redo Log Files

Filled online redo log files can be archived.
• Two advantages exist to archiving redo logs:
– Recovery: A database backup, together with online
and archived redo log files can guarantee recovery
of all committed transactions.
– Backup: Can be performed while the database is
open.
• By default a database is created in NOARCHIVELOG
Archived Redo Log Files
Information about archived logs can be obtained from V$INSTANCE.
SQL> SELECT archiver
2 FROM v$instance;
ARCHIVE
---------
STOPPED
1 row selected.
SAP BASIS Administration
(Oracle Brtools Exercise)

ARCHIVE LOG LIST;

15) Overview
A small database might need only the SYSTEM tablespace; however, Oracle
recommends that
you create additional tablespaces to store user data, user indexes, undo segments, and
temporary segments separate from data dictionary. This gives you more flexibility in
various
database administration operations and reduces contention among dictionary objects and
schema objects for the same data files.
The DBA can create new tablespaces, resize data files, add data files to tablespaces, set
and
alter default segment storage settings for segments created in a tablespace, make a
tablespace
read-only or read-write, make a tablespace temporary or permanent, and drop table
SAP BASIS Administration
(Oracle Brtools Exercise)

Database Architecture
The Oracle database architecture includes logical and physical structures that make up the
database.
• The physical structure includes the control files, online redo log files, and data files that
make up the database.
• The logical structure includes tablespaces, segments, extents, and data blocks.
The Oracle server enables fine-grained control of disk space use through tablespace and
logical storage structures, including segments, extents, and data blocks.
Tablespaces
The data in an Oracle database are stored in tablespaces.
• An Oracle database can be logically grouped into smaller logical areas of space known
as tablespaces.
• A tablespace can belong to only one database at a time.
• Each tablespace consists of one or more operating system files, which are called data
files.
8-4 Copyright © Oracle Corporation, 2001. All rights reserved.

Database Architecture (continued)

• A tablespace may consist of zero or more segments.
• Tablespaces can be brought online while the database is running.
• Except for the SYSTEM tablespace or a tablespace with an active undo segment,
tablespaces can be taken offline, leaving the database running.
SAP BASIS Administration
(Oracle Brtools Exercise)

• Tablespaces can be switched between read-write and read-only status.

Data Files
• Each tablespace in an Oracle database consists of one or more files called data files.
These are physical structures that conform with the operating system on which the
Oracle server is running.
• A data file can belong to only one tablespace.
• An Oracle server creates a data file for a tablespace by allocating the specified amount
of disk space plus a small amount of overhead.
• The database administrator can change the size of a data file after its creation or can
specify that a data file should dynamically grow as objects in the tablespace grow.
Segments
• A segment is the space allocated for a specific logical storage structure within a
tablespace. For example, all of the storage allocated to a table is a segment.
• A tablespace may consist of one or more segments.
• A segment cannot span tablespaces; however, a segment can span multiple data files
that belong to the same tablespace.
• Each segment is made up of one or more extents.
Extents
Space is allocated to a segment by extents.
• One or more extents make up a segment.

One or more extents make up a segment.

– When a segment is created, it consists of at least one extent.
– As the segment grows, extents get added to the segment.
– The DBA can manually add extents to a segment.
• An extent is a set of contiguous Oracle blocks.
• An extent cannot span a data file but must exist in one

Database Architecture (continued)

Data Blocks
The Oracle server manages the storage space in the data files in units called Oracle
blocks or
data blocks.
• At the finest level of granularity, the data in an Oracle database is stored in data blocks.
• Oracle data blocks are the smallest units of storage that the Oracle server can allocate,
read, or write.
• One data block corresponds to one or more operating system blocks allocated from an
existing data file.
• The standard data block size for an Oracle database is specified by the
DB_BLOCK_SIZE initialization parameter when the database is created.
• The data block size should be a multiple of the operating system block size to avoid
unnecessary I/O.
• The maximum data block size is dependent on the operating system

This procedure tells you how to check the archiving parameters and ARCHIVELOG mode for
SAP BASIS Administration
(Oracle Brtools Exercise)

your Oracle database and, if necessary, how to reset these. It is very important that:
The database runs in ARCHIVELOG mode
Automatic archival is enabled
After correct installation for an SAP System, the Oracle database meets both these criteria. In
this case, the online redo log files are automatically archived when full (that is, following a
redo log switch). This is important because it allows the online redo log files to be reused for
fresh archive data, so that archiving of the log files can continue at all times.
Prerequisites
The following parameters in the init.ora file control the archiving process for the Oracle
database:
Parameter Note
log_archive_start = true Preset by SAP
log_archive_dest = <directory>/<file prefix> Part of the file name
log_archive_format = <Oracle default> Use the Oracle default
log_archive_start = true causes the background archive process ARCH to be started
automatically when the database is started. This means that automatic archival mode is
enabled.
log_archive_dest defines the archive directory of the online redo log files for archiving. It
is delivered with the specification of the following SAP standard path (this example is for a
single instance installation on UNIX):
BS> <SAPDATA_HOME>/saparch/<ORACLE_SID>arch
See SAP Note 316642 for information on how to avoid an "archiver

Enter the following commands in the Oracle tool SQLPLUS:

SQLPLUS> connect internal
SQLPLUS> startup mount
SQLPLUS> alter database archivelog;
SQLPLUS> alter database open;
SQLPLUS> archive log list
SQLPLUS starts the database in ARCHIVELOG

When the database is open, you can also check the mirroring with the Oracle program
SQLPLUS:
SQLPLUS> connect internal
SQLPLUS> select * from V$logfile;

April 2002 46
a case, you must recover the original mirroring of the online redo log files as quickly as
possible.
For more information see:
Database Recovery with SQLPLUS [Page 487]
Recovery: One Inactive Redo Log Missing [Page 496]
Prerequisites
When an SAP System is installed using Oracle resources, an online redo log group normally
consists of the original online redo log file and a mirror copy of this file (that is, the group has
two members).
Procedure
This procedure describes how to check the mirroring with SAPDBA.
1. During SAPDBA startup, any missing online redo log files are displayed if the profile
parameters check_initial_settings or check_redolog_mirror are configured
properly.
See check_initial_settings [Page 199]
2. Choose Archive mode →Show all archive information: ONLINE REDO LOGS in
SAP BASIS Administration
(Oracle Brtools Exercise)

SAPDBA. Refer to Setting Archive and Database Mode with SAPDBA [Page 41].
3. When the database is open, you can also check the mirroring with the Oracle program
SQLPLUS:
SQLPLUS> connect internal
SQLPLUS> select * from V$logfile;
4. You can also make additional mirror copies. For more information, see the appropriate
Oracle documentation. In addition, many systems support hardware-based file mirroring.
For more information, see your operating system documentation.
For more information on the security of offline redo log files, see Backup of the Offline Redo
Log Files [Page 313].
13.7 Organizing Disk Storage
Use
We recommend that you store the files of the database system on different physical disks. In
this example, the control file is mirrored twice:
Disk
number
Directory Contents of directory
1 origlogA Online redo log files from the first and third
group (Set A)
2 origlogB Online redo log files from the second and
fourth group (Set B)
3 mirrorlogA Mirrored online redo log files from the first
and third group (Set A)
4 mirrorlogB Mirrored online redo log files from the
second and fourth group (Set B)
5 sapdata1 Database files, mirror of the control file
6 sapdata2 Database files, mirror of the control file
7 sapdata<n> Other database files in sapdata3 up to
sapdata<n>, each on separate disks when

13.8 Database Parameters

April 2002 48
background_dump_des
t
OS> ?/saptrace/background Directory for
database trace and database ALERT files.
If you have serious database problems, you must
analyze the information in the ALERT and trace files.
user_dump_dest OS> ?/saptrace/background Directory for user
trace files.
Tuning Parameters
The following lists a selection of RAM-dependent tuning parameters. For more information,
see the Oracle documentation.
SAP BASIS Administration
(Oracle Brtools Exercise)

Parameter Settings
ram (unit: MB)
Portion of physical RAM
that you want to reserve for
the system.
One system installed on one host:
ram = 1.0*RAM
Two systems installed on one host:
ram = 0.5*RAM
rating
Proportion of RAM taken
up by the database and the
SAP System
Default: rating=0.25 (25% of RAM reserved for the
database, 75% for the SAP System)
Database-only server: rating=0.8 (80% of RAM is
reserved for the database)
If ram<RAM*0.8: rating=1.0 (100% of RAM is
reserved for the database)
db_block_size
db_block_size
(unit: bytes) size of the
Oracle database blocks
Operating system-specific, default: 8192
The parameters ram, rating and db_block_size are taken into account when calculating
the following tuning parameters:
Parameter Determination of its value
shared_pool_size
db_block_size
(unit: bytes) buffer size for
parsed SQL statements in
the Oracle System Global
Area (SGA)
shared_pool_size=ram*rating*0.4*1024*1024
The factor 0.4 means that shared_pool_size
occupies 40% of the calculated SGA.
shared_pool_size=20.971.520 if the value
calculated using the formula above is lower than
20971520 Bytes.
db_block_buffers
db_block_size
(unit: blocks) buffer size for
data blocks and index
blocks in the Oracle SGA
db_block_buffers=ram*rating*0.6*1024*1024
/db_block_size
The factor 0.6 means that db_block_buffers
occupies 60% of the calculated SGA.
log_buffer
db_block_size
(unit: bytes) buffer size for
redo log entries in the
Oracle SGA
Default: log_buffer=327.680
Part of the SGA, which is very small when compared
SAP BASIS Administration
(Oracle Brtools Exercise)

with shared_pool_size and db_block_buffers.

Creating User Accounts with the CREATE USER

Command
The new user account can also be created with the CREATE USER
command. This command
supports more options than Enterprise Manager or Security Manager.
The Syntax for the CREATE USER Command

CREATE USER user_name

IDENTIFIED BY password
or IDENTIFIED EXTERNALLY
or IDENTIFIED GLOBALLY
AS `CN=user'
[ DEFAULT TABLESPACE ts_name ]
[ TEMPORARY TABLESPACE ts_name ]
[ QUOTA [ number K or M or UNLIMITED ] ON ts_name ]
[, QUOTA [ number K or M or UNLIMITED ] ON ts_name ]
[ PROFILE profile_name ]
[ PASSWORD EXPIRE ]
[ ACCOUNT LOCK or ACCOUNT UNLOCK ]

The parameters for this command are

l CREATE USER user_name--The CREATE USER command requires a

username for the user

you want to create.
l IDENTIFIED BYpassword--Oracle internally maintains a password for

this user. This is the

original password that is created.
l IDENTIFIED EXTERNALL --The username is authenticated in the OS.

The username must

be identical to the username defined in the OS.
l IDENTIFIED GLOBALLY AS `CNuser'--The username is

authenticated by the Oracle

security domain central server. The CN name identifies t

Modifying User Accounts

SAP BASIS Administration
(Oracle Brtools Exercise)

Modifying a user is very similar to creating one. You can modify a user with
either of the two
graphical utilities or with the ALTER USER command. As with the process
of user creation, there is
only a slight difference between the functionality of the graphical utilities
and the command-line
utility. Let's look at these operations.
NOTE: You must have the ALTER USER system privilege to modify a
user account

SYNTAX:
ALTER USER user_name
IDENTIFIED BY password
or IDENTIFIED EXTERNALLY or IDENTIFIED GLOBALLY AS `CN=user'
[ DEFAULT TABLESPACE ts_name ]
[ TEMPORARY TABLESPACE ts_name ]
[ QUOTA [ number K or M or UNLIMITED ] ON ts_name ]
[, QUOTA [ number K or M or UNLIMITED ] ON ts_name ]
[ PROFILE profile_name ]
[ PASSWORD EXPIRE ]
[ ACCOUNT LOCK or ACCOUNT UNLOCK ]
[ DEFAULT ROLE role [, role ]
or [ DEFAULT ROLE ALL [ EXCEPT role [,

Roles are very important because they are the primary way of allocating
system privileges to the user
community. Privileges can be allocated to a user either via a role or directly,
but directly can be quite
time-consuming and tedious for the DBA. By creating a role for a certain
type of user and allocating
system privileges to that role, you can cut down on the amount of work that
must be done and have an
easier way of tracking privileges

You can create, modify, and assign roles to users via Enterprise Manager,
Security Manager, or the
CREATE ROLE, ALTER ROLE, DROP ROLE, and ALTER USER
commands. In general, if you are
just changing a few roles or users, the graphical tools are very nice. If you
are modifying a large
SAP BASIS Administration
(Oracle Brtools Exercise)

number of different roles or users, it might be better to use a script, where

the SQL commands can be
saved and used again if necessary

CREATE ROLE role

NOT IDENTIFIED
Or IDENTIFIED BY password
Or IDENTIFIED EXTERNALLY
Or IDENTIFIED GLOBALLY

GRANT role or system privilege [, role or system privilege ]

TO user or role or PUBLIC [, user or role ]
[ WITH ADMIN OPTION ]

The REVOKE command is just the opposite of the GRANT command; it

will take a role or system
privilege away from a user or role:
REVOKE role or system privilege [, role or system
privilege ]
FROM user or role or PUBLIC [, user or role ]

SQL> select * from v$pq_sysstat;

STATISTIC VALUE
------------------------------ ----------
Servers Busy 0
Servers Idle 12
Servers Highwater 16
Server Sessions 380
Servers Started 4
Servers Shutdown 4
Servers Cleaned Up 0
Queries Initiated 21
DFO Trees 77
Local Msgs Sent 2459361
Distr Msgs Sent 0
Local Msgs Recv'd 2459318
Distr Msgs Recv'd 0
OUTPUT: