Professional Documents
Culture Documents
Dynamic SGA
Since its inception, the SGA has always been a static allocation of memory, which was shared
across all Oracle threads of execution. Beginning with Oracle9i, the dynamic SGA
infrastructure will allow for the sizing of the Buffer Cache, Shared Pool, and the Large Pool
without having to shutdown the instance, modify the initialization parameter file, and restart the
instance. In addition, the dynamic SGA infrastructure will allow limits to be set at run time on
how much physical memory will be used for the SGA. Instances will be started under-
configured and allow the instance to use as much memory as the operating system gives it.
A database administrator grow a component’s SGA use by issuing an alter system command to
modify the init.ora parameters value. Oracle takes the new size, rounds it up to the nearest
multiple of 16MB and adds or takes away granules to meet the target size.
Adding a number of granules to a component (increasing the memory use of a component) with
an with an alter system command will succeed if Oracle has enough free granules to satisfy the
request. Oracle does not start freeing another component’s granules for adding. Instead, the
database administrator must ensure the instance has enough free granules to satisfy the increase
of a component’s granule use. If the current amount of SGA memory is less than
MAX_SGA_SIZE, then Oracle is free to allocate more granules until the SGA size reaches
MAX_SGA_SIZE.
The Oracle server, which invokes the alter system command reserves a set of granules for the
corresponding SGA component (init.ora parameter which defines the component’s SGA use).
After the reservation is complete, the foreground hands the completion to the background
process. The background process completes the operation by taking the reserved granules and
adding them to the component’s granule list. This is also referred to as growing a components
SGA memory area.
OMF Configurations
Two basic OMF configuration exist. The first, a single initialization parameter,
DB_CREATE_FILE_DEST is specified. All the data files, control files, and online logs are created
in the same file system location. The second configuration and the preferred is setting two
initialization parameters. DB_CREATE_FILE_DEST is set to give the default location for data
files. DB_CREATE_ONLINE_LOG_DEST_n is set to give the default location(s) for online logs
and control files. This second configuration provides good separation of data files, online redo logs,
and optional Oracle multiplexing of online redo logs and control files where N is an integer between
1 and 5 (For example: DEST_1, DEST_2, ...DEST_5).
OMF Example
The DB_CREATE_FILE_DEST parameter sets the default file system directory for the data files
(/u01/oradata).
The DB_CREATE_ONLINE_LOG_DEST_1 and DB_CREATE_ONLINE_LOG_DEST_2 set the
default file system directories for online redo log and control file creation.
Each online redo log and control file is multiplexed across the two directories; /u02/oradata and
/u03/oradata.
Once the initialization parameters are set, the database can be created using the CREATE
DATABASE command. If the command fails, any OMF files created are removed. The internally
generated file names can be seen when selecting from DBA_DATAFILES and V$LOGFILE.
Delete Datafiles
DROP TABLESPACE
The DATAFILES option will delete the operating system files associated with the
tablespace.
ALTER DATABASE TEMPFILE
The DROP INCLUDING DATAFILES option will drop the tempfile from the
database and delete the operating system file associated with it. The tablespace
remains. A message will be written to the ALERT.LOG file for each file deleted.
The command will succeed even if an operating system error prevents the deletion
of the file.
B Extents BMB
I
T
M BMB BMB
A
P
BMB BMB
S
E
DATA
G
M
E
N
T Block
B
I
T
• Low High Water Mark
M (LHWM) indicates
A blocks below this
P mark are formatted.
S • High High Water
E Mark (HHWM)
G
M
indicates blocks
E above this mark are
N not formatted.
T
LHWM HHWM
UNDO Tablespace
Note in the creation of an UNDO tablespace, the DATAFILE clause is the only
clause allowed.
UNDO Tablespace for Real Application Cluster
An UNDO tablespace must be created per instance.
• Where:
– SPFILE-NAME: is the name of the SPFILE
to be created. If not specified, the default
SPFILE name is assumed.
– PFILE-NAME: is the name of a PFILE
which must be available on the server side.
Exporting an SPFILE
The contents of an SPFILE can be exported into an old-style PFILE in order to
make modifications to the SPFILE by first exporting it, editing the output file, then
recreating it.
Exporting an SPFILE to a PFILE can also be used to create backups of the
persistent parameter file. NOTE: With Oracle9i, this would be a secondary
method as RMAN can also backup persistent parameter files.
Lastly, exporting an SPFILE can be used to provide a list of parameter values
much the same as SHOW PARAMETER.
V$SPPARAMETER
The view will return NULL values if a PFILE was used to startup the instance.
OLTP
BATCH ACTIVE_SESSION_POOL_P1 = 5
QUEUEING_P1 = 600
Advantages
• Using Oracle Names servers as LDAP proxies
helps makes the migration to LDAP seamless.
• Clients that are too old to "speak" LDAP can
continue name resolution from their traditional
source.
• Administration of the name/address data is
optimized, providing a single point of definition
for all data.
• Simultaneous use of both ONames and LDAP
without requiring that both systems be
maintained separately.
{
if the DN isn't an OrclCtx, query the subtree for
OracleContexts
. = (DATA_LIST=(FLAGS=0x11)
(DATA=(TYPE=ns.smd.)(NAME=svrroot.)))
svrroot. = (DATA_LIST=(FLAGS=0x209)
(DATA=(TYPE=a.smd.)(ADDRESS=(PROTOCOL=TCP)(Port=1575)(host= nineva)))
(DATA=(TYPE=tos.npd.omd.)(CTEXT=ORACLE_NAMESERVER))
(DATA=(TYPE=host.nm.omd.)(TEXT=nineva)))
south. = (DATA_LIST=(FLAGS=0x3)
(DATA=(TYPE=ns.smd.)(NAME=svr.south.)))
svr.south. = (DATA_LIST=(FLAGS=0x5)
(DATA=(TYPE=a.smd.)(ADDRESS=(PROTOCOL=tcp)
(HOST=oranamesrvr5)(PORT=1575)))
0x8 Specifies that the Oracle Names LDAP Proxy server is authoritative
0x200 Identifies the Oracle Names LDAP Proxy server who wrote the
CKPTOP.ORA file
Flag Values
Understanding how the flag values are calculated will help in troubleshooting topology related
errors as well as authoritative problems. Each hex value corresponds to an element of the
topology or some characteristic of an element. Several values can be combined to fully
describe an element. The values were chosen in such a manner as to always provide a sum that
can be calculated in one way only. The following examples illustrate this.
In the sample CKPTOP.ORA file, the root domain has a hexadecimal sum of 0x11 that is
created from the following equation:
0x1 + 0x10 = 0x11
The svvroot root Oracle Names LDAP Proxy server has a hexadecimal sum of 0x209 that is
created from the equation:
0x1 + 0x8 + 0x200 = 0x209
The delegated domain south has a hexadecimal sum of 0x3 that is created from the equation:
0x1 + 0x2 = 0x3
The svr.south delegated Oracle Names LDAP Proxy server has a hexadecimal sum of 0x5
that is created from the equation:
0x1 + 0x4 = 0x5
0x10 and 0x8 represent authoritative domains and authoritative Oracle Names LDAP Proxy
servers respectively. 0x2 and 0x4 represent delegated domains and delegated Oracle Names
LDAP Proxy servers respectively.