RMAN Incremental Backups
RMANincremental backups backup only datafile blocks that have
changed since a specified previous backup. We can make incremental
backups of databases, individual tablespaces or datafiles.
The primary reasons for making incremental backups parts of your
strategy are:
For use in a strategy based on incrementally updated backups,
where these incremental backups are used to periodically roll
forward an image copy of the database
To reduce the amount of time needed for daily backups
To save network bandwidth when backing up over a network
To be able to recover changes to objects created with
theNOLOGGINGoption. For example, direct load inserts do not create
redo log entries and their changes cannot be reproduced with media
recovery. They do, however, change data blocks and so are captured
by incremental backups.
To reduce backup sizes forNOARCHIVELOGdatabases. Instead of
making a whole database backup every time, you can make incremental
backups.As with full backups, if you are inARCHIVELOGmode, you can
make incremental backups if the database is open; if the database
is inNOARCHIVELOGmode, then you can only make incremental backups
after a consistent shutdown.
One effective strategy is to make incremental backups to disk,
and then back up the resulting backup sets to a media manager
withBACKUPASBACKUPSET. The incremental backups are generally
smaller than full backups, which limits the space required to store
them until they are moved to tape. Then, when the incremental
backups on disk are backed up to tape, it is more likely that tape
streaming can be sustained because all blocks of the incremental
backup are copied to tape. There is no possibility of delay due to
time required for RMAN to locate changed blocks in the
datafiles.
RMAN backups can be classified in these ways:
Full or incremental
Open or closed
Consistent or inconsistent
Note that these backup classifications apply only to datafile
backups. Backups of other files, such as archivelogs and control
files, always include the complete file and are never
inconsistent.
Backup TypeDefinition
FullA backup of a datafile that includes every allocated block
in the file being backed up. A full backup of a datafile can be an
image copy, in which case every data block is backed up. It can
also be stored in a backup set, in which case datafile blocks not
in use may be skipped.
A full backup cannot be part of an incremental backup strategy;
that is, it cannot be the parent for a subsequent incremental
backup.
IncrementalAn incremental backup is either a level 0 backup,
which includes every block in the file except blocks compressed out
because they have never been used, or a level 1 backup, which
includes only those blocks that have been changed since the parent
backup was taken.
A level 0 incremental backup is physically identical to a full
backup. The only difference is that the level 0 backup is recorded
as an incremental backup in the RMAN repository, so it can be used
as the parent for a level 1 backup.
OpenA backup of online, read/write datafiles when the database
is open.
ClosedA backup of any part of the target database when it is
mounted but not open. Closed backups can be consistent or
inconsistent.
ConsistentA backup taken when the database is mounted (but not
open) after a normal shutdown. The checkpoint SCNs in the datafile
headers match the header information in the control file. None of
the datafiles has changes beyond its checkpoint. Consistent backups
can be restored without recovery.
Note:If you restore a consistent backup and open the database in
read/write mode without recovery, transactions after the backup are
lost. You still need to perform anOPEN RESETLOGS.
InconsistentA backup of any part of the target database when it
is open or when a crash occurred orSHUTDOWNABORTwas run prior to
mounting.
An inconsistent backup requires recovery to become
consistent.
The goal of an incremental backup is to back up only those data
blocks that have changed since a previous backup. You can use RMAN
to create incremental backups of datafiles, tablespaces, or the
whole database.
During media recovery, RMAN examines the restored files to
determine whether it can recover them with an incremental backup.
If it has a choice, then RMAN always chooses incremental backups
over archived logs, as applying changes at a block level is faster
than reapplying individual changes.
RMAN does not need to restore a base incremental backup of a
datafile in order to apply incremental backups to the datafile
during recovery. For example, you can restore non-incremental image
copies of the datafiles in the database, and RMAN can recover them
with incremental backups.
Incremental backups allow faster daily backups, use less network
bandwidth when backing up over a network, and provide better
performance when tape I/O bandwidth limits backup performance. They
also allow recovery of database changes not reflected in the redo
logs, such as direct load inserts. Finally, incremental backups can
be used to back upNOARCHIVELOGdatabases, and are smaller than
complete copies of the database (though they still require a clean
database shutdown).
One effective strategy is to make incremental backups to disk
(as image copies), and then back up these image copies to a media
manager withBACKUPASBACKUPSET. Then, you do not have the problem of
keeping the tape streaming that sometimes occurs when making
incremental backups directly to tape. Because incremental backups
are not as big as full backups, you can create them on disk more
easily.
Incremental Backup AlgorithmEach data block in a datafile
contains a system change number (SCN), which is the SCN at which
the most recent change was made to the block. During an incremental
backup, RMAN reads the SCN of each data block in the input file and
compares it to the checkpoint SCN of the parent incremental backup.
If the SCN in the input data block is greater than or equal to the
checkpoint SCN of the parent, then RMAN copies the block.
Note that if you enable the block change tracking feature, RMAN
can refer to the change tracking file to identify changed blocks in
datafiles without scanning the full contents of the datafile. Once
enabled, block change tracking does not alter how you take or use
incremental backups, other than offering increased performance.
Level 0 and Level 1 Incremental BackupsIncremental backups can
be either level 0 or level 1.A level 0 incremental backup, which is
the base for subsequent incremental backups, copies all blocks
containing data, backing the datafile up into a backup set just as
a full backup would. The only difference between a level 0
incremental backup and a full backup is that a full backup is never
included in an incremental strategy.
A level 1 incremental backup can be either of the following
types:
Adifferential backup, which backs up all blocks changed after
the most recent incremental backup at level 1 or 0
Acumulative backup, which backs up all blocks changed after the
most recent incremental backup at level 0
Incremental backups are differential by default.
Note:Cumulative backups are preferable to differential backups
when recovery time is more important than disk space, because
during recovery each differential backup must be applied in
succession. Use cumulative incremental backups instead of
differential, if enough disk space is available to store cumulative
incremental backups.
The size of the backup file depends solely upon the number of
blocks modified and the incremental backup level.
Differential Incremental BackupsIn a differential level 1
backup, RMAN backs up all blocks that have changed since the most
recent cumulative or differential incremental backup, whether at
level 1 or level 0. RMAN determines which level 1 backup occurred
most recently and backs up all blocks modified after that backup.
If no level 1 is available, RMAN copies all blocks changed since
the level 0 backup.
The following command performs a level 1 differential
incremental backup of the database:
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;
If no level 0 backup is available, then the behavior depends
upon the compatibility mode setting. If compatibility is
>=10.0.0, RMAN copies all blocks changed since the file was
created, and stores the results as a level 1 backup. In other
words, the SCN at the time the incremental backup is taken is the
file creation SCN. If compatibility alter system
[SID=instance-name] reset parameter-name; New DIAGNOSTIC_DEST
parameter as replacement for BACKGROUND_DUMP_DEST, CORE_DUMP_DEST
and USER_DUMP_DEST. It defaults to $ORACLE_BASE/diag/.
From 11g, we havetwo alert log files. One is the
traditionalalert_SID.log(inDIAGNOSTIC_DEST/trace) and the other one
is alog.xmlfile(inDIAGNOSTIC_DEST/alert). The xml file gives a lot
more information than the traditional alert log file. We can have
logging information for DDL operations in the alert log files. If
log.xml reaches 10MB size, it will be renamed and will create new
alert log file. log.xml can be accessed from ADR command
line.ADRCI>show alert Logging information for DDL operations
will be written into alert log files, is not enabled by default and
we must change the new parameter to TRUE.SQL>ALTER SYSTEM SET
enable_ddl_logging=TRUE SCOPE=BOTH; Parameter(p) file & server
parameter(sp) file can be created from memory.SQL>create
pfile[=location] from memory;SQL>create spfile[=location] from
memory; From 11g, server parameter file(spfile)is in new format
that is compliant with Oracle Hardware Assisted Resilient
Data(HARD).
DDL wait option - Oracle will automatically wait for the
specified time period during DDL operations and will try to run the
DDL again.SQL>ALTER SYSTEM/SESSION SET DDL_LOCK_TIMEOUT = n; We
can define thestatisticsto be pending, which means newly gather
statistics will not be published or used by the optimizer giving us
an opportunity to test the new statistics before we publish
them.
From Oracle Database 11g, we can create extended statistics
on(i) expressions of values, not only on columns(ii) on multiple
columns (column group), not only on single column.
Table level control of CBO statistics refresh threshold.SQL>
exec dbms_stats.set_table_prefs(HR, EMP, STALE_PERCENT, 20');
Flashback Data Archive- flashback will make use offlashbacklogs,
explicitly created for that table, in FRA (Flash/Fast Recovery
Area), will not use undo. Flashback data archives can be defined on
any table/tablespace. Flashback data archives are written by a
dedicatedbackground processcalled FBDA so there is less impact on
performance. Can be purged at regular intervals automatically.
Analytic Workspace Manager(AWM) - a tool to manage OLAP objects
in the database.
Users with default passwords can be found in
DBA_USERS_WITH_DEFPWD.
Hash value of the passwords in DBA_USERS (in ALL_USERS and
USER_USERS) will be blank. If you want to see the value, query
USER$.
Default value for audit_trail is DB, not NULL. By default some
system privileges will beaudited.
LogMiner can be accessed from Oracle Enterprise Manager.
Data Guard improvements
OracleActive Data Guard- Standby databases can now
simultaneously be in read and recovery mode - so use it for running
reports 24x7.
Online upgrades: Test on standby and roll to primary.
Snapshot standby database- physical standby database can be
temporarily converted into an updateable one called snapshot
standby database.
Creation of physical standby is become easier.
From Oracle 11g, we can control archive log deletion by setting
the log_auto_delete initialization parameter to TRUE. The
log_auto_delete parameter must be coupled with the
log_auto_del_retention_target parameter to specify the number of
minutes an archivelog is maintained until it is purged. Default is
24 hours (1440 minutes).
Incremental backup on physical readable physical standby.
Offload: Complete database and fast incremental backups.
Logical standby databases now support XML and CLOB datatypes as
well as transparent data encryption.
We can compress the redo data that goes to the standby server,
by settingcompression=enable.
From Oracle 11g, logical standby provides support for
DBMS_SCHEDULER.
When transferring redo data to standby, if the standby does not
respond in time, the log transferring service will wait for
specified timeout value (set bynet_timeout=n) and then give up.
New package and procedure, DBMS_DG.INITIATE_FS_FAILOVER,
introduced to programmatically initiate a failover.
SecureFilesSecureFiles provide faster access to unstructured
data than normal file systems, provides the benefits of LOBs and
external files. For example, write access to SecureFiles is faster
than a standard Linux file system, while read access is about the
same.SecureFiles can be encrypted for security, de-duplicated and
compressed for more efficient storage, cached (or not) for faster
access (or save the buffer cache space), and logged at several
levels to reduce the mean time to recover (MTTR) after a crash.
create table table-name ( ... lob-column lob-type [deduplicate]
[compress high/low] [encrypt using 'encryption-algorithm']
[cache/nocache] [logging/nologging] ...) lob (lob-column) store as
securefile ...;
To create SecureFiles:(i) The initialization parameter
db_securefile should be set to PERMITTED (the default value).(ii)
The tablespace where we are creating the securefile should be
Automatic Segment Space Management (ASSM) enabled (default mode in
Oracle Database 11g).
Real Application Testing(RAT)Real Application Testing (RAT) will
make decision making easier in migration, upgradation, patching,
initialization parameter changes, object changes, hardware
replacements, and operating system changes and moving to RAC
environment. RAT consists of two components:
Database Replay- capture production workload and replay on
different (standby/test/development) environment. Capture the
activities from source database in the form of capture files in
capture directory. Transfer these files to target box. Replay the
process on target database.
SQL Performance Analyzer (SPA)- identifies SQL execution plan
changes and performance regressions. SPA allows us to get results
of some specific SQL or entire SQL workload against various types
of changes such as initialization parameter changes,
optimizerstatisticsrefresh, and database upgrades, and then
produces a comparison report to help us assess their impact.
Accessible through Oracle Enterprise Manager or dbms_sqlpa
package.
Other features
Temporary tablespaceor it's tempfile can be shrinked, up to
specified size.SQL>alter tablespace temp-tbs shrink
space;SQL>alter tablespace temp-tbs shrink space keep
n{K|M|G|T|P|E};SQL> alter tablespace temp-tbs shrink tempfile
'.../temp03.dbf' keepn{K|M|G|T|P|E};We can check free temp space in
new viewDBA_TEMP_FREE_SPACE.
From 11g, while creating global temporary tables, we can specify
TEMPORARY tablespaces.
Online application upgrades andhot patching. Features based
patching is also available.
Real-time SQL Monitoring, allows us to see the different metrics
of the SQL being executed in real time. The stats are exposed
through V$SQL_MONITOR, which is refreshed every second.
"duality" between SQL and XML - users can embed XML within
PL/SQL and vice versa.
New binary XML datatype, a new XML index & better XQuery
support.
Query rewriting will occur more frequently and for remote tables
also.
Automatic Diagnostic Repository(ADR)- automated capture of fault
diagnostics for faster fault resolution. The location of the files
depends on DIAGNOSTIC_DEST parameter. This can be managed from
Database control or command line. For command line, execute $
./adrci Repair advisorsto guide DBAs through the fault diagnosis
and resolution process.
SQL Developeris installed with the database server software (all
editions). The Windows SQL*Plus GUI is deprecated.
APEX(Oracle Application Express), formerly known as HTML DB,
shipped with the DB.
Checkers - DB Structure Integrity Checker, Data Block Integrity
Checker, Redo Integrity Checker, Undo Segment Integrity Checker,
Transaction Integrity Checker, Dictionary Integrity Checker.
11g SQL Access Advisor provides recommendations with respect to
the entire workload, including considering the cost of creation and
maintaining access structure.
hangman Utility hangman(Hang Manager) utility to detect database
bottlenecks.
Health Monitor (HM) utility - Health Monitor utility is an
automation of the dbms_repair corruption detection utility.
The dbms_stats package has several new procedures to aid in
supplementing histogram data, and the state of these extended
histograms can be seen in the
user_tab_col_statisticsview:dbms_stats.create_extended_statsdbms_stats.show_extended_stats_namedbms_stats.drop_extended_stats
New package DBMS_ADDM introduced in 11g.
Oracle 11g introduced server side connection pool called
Database Resident Connection Pool (DRCP).
Desupported featuresThe following features are
desupported/deprecated in Oracle Database 11gRelease 1
(11.1.0):
Oracle export utility (exp).Impis still supported for backwards
compatibility.
Windows SQL*Plus GUI & iSQLPlus will not be shipped anymore.
Use SQL Developer instead.
Oracle Enterprise Manager Java console.
copy command is deprecated.
What's New in Oracle 10g
The following new features were introduced with Oracle 10g:
Oracle 10gRelease 1 (10.1.0) - January 2004 Grid computing - an
extension of the clustering feature (Real Application
Clusters).
SYSAUXtablespace has been introduced as an auxiliary to SYSTEM,
as LOCAL managed tablespace.
Datapump- faster data movement withexpdp and impdp, successor
for normalexp/imp.
NIDutilityhas been introduced to change the database name and
id.
Oracle Enterprise Manager (OEM) became browser based. Through
any browser we can access data of a database in Oracle Enterprise
Manager Database Control. Grid Control is used for
accessing/managing multiple instances.
Automated Storage Management (
HYPERLINK
"http://satya-dba.blogspot.com/2010/03/automatic-storage-management-asm-10g.html"ASM
HYPERLINK
"http://satya-dba.blogspot.com/2010/03/automatic-storage-management-asm-10g.html").
ASMB, RBAL, ARBx are the newbackground processesrelated to ASM.
Manageability improvements (self-tuning features).
Performance and scalability improvements.
Automatic Workload Repository (AWR).
Automatic Database Diagnostic Monitor (ADDM).
Active Session History (ASH).
Flashbackoperations available on row, transaction, table or
database level.
Ability to UNDROP (FlashbackDrop) a table using arecycle bin.
Ability to rename tablespaces (except SYSTEM and SYSAUX), whether
permanent ortemporary, using the following command:SQL> ALTER
TABLESPACE oldname RENAME TO newname;
Ability totransport tablespacesacross platforms (e.g. Windows to
Linux, Solaris to HP-UX), which has same ENDIAN formats. If ENDIAN
formats are different we have to useRMAN.
In Oracle 10g,undo tablespacecan guarantee the retention of
unexpired undo extents.SQL> CREATE UNDO TABLESPACE ... RETENTION
GUARANTEE;SQL> ALTER TABLESPACE UNDO_TS RETENTION GUARANTEE; New
'drop database' statement, will delete the datafiles, redolog files
mentioned in control file and will delete SP file also.SQL>
STARTUP RESTRICT MOUNT EXCLUSIVE;SQL> DROP DATABASE;
New memory structure in SGA i.e. Streams pool
(streams_pool_sizeparameter), useful fordatapumpactivities &
streams replication.
Introduced new init parameter,sga_target,to change the value of
SGA dynamically. This is called Automatic Shared Memory Management
(ASMM). It includes buffer cache, shared pool, java pool and large
pool. It doesn't include log buffer, streams pool and the buffer
pools for nonstandard block sizes and the non-default ones for KEEP
or RECYCLE.SGA_TARGET = DB_CACHE_SIZE + SHARED_POOL_SIZE +
JAVA_POOL_SIZE + LARGE_POOL_SIZE
Newbackground processesin Oracle 10g
Memory Manager (maximum 1) MMAN - MMAN dynamically adjust the
sizes of the SGA components like DBC, large pool, shared pool and
java pool. It is a new process added to Oracle 10g as part of
automatic shared memory management.
Memory Monitor (maximum 1) MMON - MMON monitors SGA and performs
various manageability related background tasks.
Memory Monitor Light (maximum 1) MMNL - New background process
in Oracle 10g.
Change Tracking Writer (maximum 1) CTWR - CTWR will be useful in
RMAN.
ASMB - This ASMB process is used to provide information to and
from cluster synchronization services used by ASM to manage the
disk resources. It's also used to updatestatisticsand provide a
heart beat mechanism.
Re-Balance RBAL - RBAL is the ASM related process that performs
rebalancing of disk resources controlled by ASM.
Actual Rebalance ARBx - ARBx is configured by
ASM_POWER_LIMIT.
DBA can specify a default tablespace for the database.
Temporary tablespace groupsto group multipletemporary
tablespacesinto a single group.
From Oracle Database 10g, the ability to prepare the primary
database and logical standby for a switchover, thus reducing the
time to complete the switchover.On primary,ALTER DATABASE PREPARE
TO SWITCHOVER TO LOGICAL STANDBY;
On logical standby,
ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
New packages
DBMS_SCHEDULER, which can call OS utilities and programs, not
just PL/SQL program units like DBMS_JOB package. By using this
package we can create jobs, programs, schedules and job
classes.
DBMS_FILE_TRANSFER package to transfer files.
DBMS_MONITOR, to enable end-to-end tracing (tracing is not done
only by session, but by client identifier).
DBMS_ADVISOR, will help in working with several advisors.
DBMS_WORKLOAD_REPOSITORY, to aid AWR, ADDM, ASH.
Support for bigfile tablespaces are up to 8EB (Exabytes) in
size.
Rules-Based Optimizer (RBO) is desupported (not deprecated).
Auditing: FGA (Fine-grained auditing) now supports DML
statements in addition to selects.
New features inRMAN Managing recovery related files
withflash/fast recovery area.
Optimized incremental backups using block change tracking
(Faster incremental backups) using a file (namedblock change
tracking file). CTWR (Change Tracking Writer) is thebackground
processresponsible for tracking the blocks.
Reducing the time and overhead of full backups with
incrementally updated backups.
Comprehensive backup job tracking and administration with
Enterprise Manager.
Backup set binary compression.
New compression algorithm BZIP2 brought in.
Automated Tablespace Point-in-Time Recovery.
Automatic channel failover on backup & restore.
Cross-platform tablespace conversion.
Ability to preview the backups required to perform a restore
operation.RMAN> restore database preview [summary];RMAN>
restore tablespace tbs1 preview;
SQL*Plus enhancements
The defaultSQL> promptcan be changed by setting the below
parameters in $ORACLE_HOME/sqlplus/admin/glogin.sql
_connect_identifier (will prompt DBNAME>)
_date (will prompt DATE>)
_editor
_o_version
_o_release
_privilege (will prompt AS SYSDBA> or AS SYSOPER> orAS
SYSASM>)
_sqlplus_release
_user (will prompt USERNAME>)
From 10g, thelogin.sqlfile is not only executed at SQL*Plus
startup time, but also at connect time as well. So SQL prompt will
be changed after connect command.Now we can login as SYSDBA without
the quotation marks.sqlplus / as sysdba(as well as oldsqlplus "/ as
sysdba"orsqlplus '/ as sysdba'). This enhancement not only means we
have two fewer characters to type, but provides some additional
benefits such as not requiring escape characters in operating
systems such as Unix.From Oracle 10g, the spool command can append
to an existing one.SQL> spool result.log append10g allows us to
save statements as appended to the files.SQL> Query1 ....SQL>
save myscriptsSQL> Query2 ....SQL> save myscripts
appenddescribe command can give description of rules and rule
sets.Virtual Private Database (VPD) has grown into a very powerful
feature with the ability to support a variety of requirements, such
as masking columns selectively based on the policy and applying the
policy only when certain columns are accessed. The performance of
the policy can also be increased through multiple types of policy
by exploiting the nature of the application, making the feature
applicable to multiple situations.
We can now shrink segments, tables and indexes to reclaim free
blocks, provided that Automatic Segment Space Management (ASSM) is
enabled in the tablespace.SQL> alter table table-name shrink
space;
From 10g,statisticsare collected automatically if
STATISTIC_LEVEL is set to TYPICAL or ALL. No need of ALTER TABLE
... MONITORING command.
Statistics can be collected for SYS schema, data dictionary
objects and fixed objects (x$ tables).
Complete refresh ofmaterialized viewswill do delete, instead of
truncate, by setting ATOMIC_REFRESH to TRUE.
Introduced Advisors
SQL Access Advisor
SQL Tune Advisor
Memory Advisor
Undo AdvisorSegment Advisor
MTTR (Mean Time To Recover) Advisor
Oracle 10gRelease 2 (10.2.0) - September 2005 Newasmcmd
utilityfor managingASMstorage.
Async COMMITs.
Passwords for DB Links are encrypted.
Transparent Data Encryption.
Fast Start Failover for Data Guard was introduced in Oracle 10g
R2.
The CONNECT role can now only connect (CREATE privileges are
removed).Before 10g,
SQL> select PRIVILEGE from role_sys_privs where
ROLE='CONNECT';
PRIVILEGE
----------------------------------------
CREATE VIEW
CREATE TABLE
ALTER SESSION
CREATE CLUSTER
CREATE SESSION
CREATE SYNONYM
CREATE SEQUENCE
CREATE DATABASE LINK
From 10g,
SYS> select PRIVILEGE from role_sys_privs where
ROLE='CONNECT';
PRIVILEGE
----------------------------------------
CREATE SESSION
Undo Tablespace/Undo Management in Oracle
Oracle9iintroduced undo.
What Is Undo and Why?Oracle Database has a method of maintaining
information that is used to rollback or undo the changes to the
database. Oracle Database keeps records of actions of transactions,
before they are committed and Oracle needs this information to
rollback or undo the changes to the database. These records are
calledrollback or undo records.
These records are used to:
Rollback transactions - when a ROLLBACK statement is issued,
undo records are used to undo changes that were made to the
database by the uncommitted transaction.
Recover the database - during database recovery, undo records
are used to undo any uncommitted changes applied from the redo log
to the data files.
Provide read consistency - undo records provide read consistency
by maintaining the before image of the data for users who are
accessing the data at the same time that another user is changing
it.
Analyze data as of an earlier point in time by usingFlashback
Query.
Recover from logical corruptions usingFlashbackfeatures.
Until Oracle 8i, Oracle usesrollback segmentsto manage the undo
data.Oracle9iintroduced automatic undo management, which allows the
dba to exert more control on how long undo information is retained,
simplifies undo space management and also eliminates the complexity
of managing rollback segments. Oracle strongly recommends that you
use undo tablespace to manage undo rather than rollback
segments.
Space for undo segments is dynamically allocated, consumed,
freed, and reused all under the control of Oracle Database, rather
than by DBA.
From Oracle 9i, the rollback segments method is referred as
"Manual Undo Management Mode" and the new undo tablespaces method
as the "Automatic Undo Management Mode".
Notes: Although both rollback segments and undo tablespaces are
supported, both modes cannot be used in the same database instance,
although for migration purposes it is possible, for example, to
create undo tablespaces in a database that is using rollback
segments, or to drop rollback segments in a database that is using
undo tablespaces. However, you must bounce the database in order to
effect the switch to another method of managing undo.
System rollback segment exists in both the modes.
When operating in automatic undo management mode, any manual
undo management SQL statements and initialization parameters are
ignored and no error message will be issued e.g. ALTER ROLLBACK
SEGMENT statements will be ignored.
Automatic Undo ManagementUNDO_MANAGEMENTThe following
initialization parameter setting causes theSTARTUP commandto start
an instance in automatic undo management mode:
UNDO_MANAGEMENT = AUTO
The default value for this parameter is MANUAL i.e. manual undo
management mode.
UNDO_TABLESPACEUNDO_TABLESPACE an optional dynamic parameter,
can be changed online,specifying the name of an undo tablespace to
use.An undo tablespace must be available, into which the database
will store undo records. The default undo tablespace is created at
database creation, or an undo tablespace can be created
explicitly.
When the instance starts up, the database automatically selects
for use the first available undo tablespace. If there is no undo
tablespace available, the instance starts, but uses the SYSTEM
rollback segment for undo. This is not recommended, and an alert
message is written to the alert log file to warn that the system is
running without an undo tablespace. ORA-01552 error is issued for
any attempts to write non-SYSTEM related undo to the SYSTEM
rollback segment.
If the database contains multiple undo tablespaces, you can
optionally specify at startup that you want an Oracle Database
instance to use a specific undo tablespace. This is done by setting
the UNDO_TABLESPACE initialization parameter.
UNDO_TABLESPACE = undotbs
In this case, if you have not already created the undo
tablespace, the STARTUP command will fail. The UNDO_TABLESPACE
parameter can be used to assign a specific undo tablespace to an
instance in an OracleReal Application Clusters
(RAC)environment.
To findout the undo tablespaces in databaseSQL>select
tablespace_name, contents from dba_tablespaces where contents =
'UNDO';To findout the current undo tablespace
SQL> show parameterundo_tablespace(OR)
SQL>select VALUE from v$parameter where
NAME='undo_tablespace';UNDO_RETENTIONCommitted undo information
normally is lost when its undo space is overwritten by a newer
transaction. However, for consistent read purposes, long-running
queries sometimes require old undo information for undoing changes
and producing older images of data blocks. The success of several
Flashbackfeatures can also depend upon older undo information.
The default value for the UNDO_RETENTION parameter is 900.
Retention is specified in units of seconds. This value specifies
the amount of time, undo is kept in the tablespace. The system
retains undo for at least the time specified in this parameter.
You can set the UNDO_RETENTION in the parameter file:
UNDO_RETENTION = 1800
You can change the UNDO_RETENTION value at any time using:
SQL>ALTER SYSTEM SET UNDO_RETENTION = 2400;The effect of the
UNDO_RETENTION parameter is immediate, but it can only be honored
if the current undo tablespace has enough space. If an active
transaction requires undo space and the undo tablespace does not
have available space, then the system starts reusing unexpired undo
space (if retention is not guaranteed). This action can potentially
cause some queries to fail with the ORA-01555 "snapshot too old"
error message.
UNDO_RETENTION applies to both committed and uncommitted
transactions since the introduction offlashback queryfeature in
Oracle needs this information to create a read consistent copy of
the data in the past.
Oracle Database 10gautomatically tunes undo retention by
collecting database usestatisticsand estimating undo capacity needs
for the successful completion of the queries. You can set a low
threshold value for the UNDO_RETENTION parameter so that the system
retains the undo for at least the time specified in the parameter,
provided that the current undo tablespace has enough space. Under
space constraint conditions, the system may retain undo for a
shorter duration than that specified by the low threshold value in
order to allow DML operations to succeed.
The amount of time for which undo is retained for Oracle
Database for the current undo tablespace can be obtained by
querying the TUNED_UNDORETENTION column of the V$UNDOSTAT dynamic
performance view.
SQL>select tuned_undoretention from v$undostat;Automatic
tuning of undo retention is not supported for LOBs. The RETENTION
value for LOB columns is set to the value of the UNDO_RETENTION
parameter.
UNDO_SUPRESS_ERRORSIn case your code has the alter transaction
commands that perform manual undo management operations. Set this
to true to suppress the errors generated when manual management SQL
operations are issued in an automated management mode.
UNDO_SUPRESS_ERRORS = false
Retention GuaranteeOracle Database 10glets you guarantee undo
retention. When you enable this option, the database never
overwrites unexpired undo data i.e. undo data whose age is less
than the undo retention period. This option is disabled by default,
which means that the database can overwrite the unexpired undo data
in order to avoid failure of DML operations if there is not enough
free space left in the undo tablespace.
You enable the guarantee option by specifying the RETENTION
GUARANTEE clause for the undo tablespace when it is created by
either the CREATE DATABASE or CREATE UNDO TABLESPACE statement or
you can later specify this clause in an ALTER TABLESPACE statement.
You do not guarantee that unexpired undo is preserved if you
specify the RETENTION NOGUARANTEE clause.
In order to guarantee the success of queries even at the price
of compromising the success of DML operations, you can enable
retention guarantee. This option must be used with caution, because
it can cause DML operations to fail if the undo tablespace is not
big enough. However, with proper settings, long-running queries can
complete without risk of receiving the ORA-01555 "snapshot too old"
error message, and you can guarantee a time window in which the
execution of Flashback features will succeed.
From 10g, you can use the DBA_TABLESPACES view to determine the
RETENTION setting for the undo tablespace. A column named RETENTION
will contain a value on GUARANTEE, NOGUARANTEE, or NOT APPLY (used
for tablespaces other than the undo tablespace).
A typical use of the guarantee option is when you want to ensure
deterministic and predictable behavior of Flashback Query by
guaranteeing the availability of the required undo data.
Size of Undo TablespaceYou can size the undo tablespace
appropriately either by using automatic extension of the undo
tablespace or by manually estimating the space.
Oracle Database supports automatic extension of the undo
tablespace to facilitate capacity planning of the undo tablespace
in the production environment. When the system is first running in
the production environment, you may be unsure of the space
requirements of the undo tablespace. In this case, you can enable
automatic extension for datafiles of the undo tablespace so that
they automatically increase in size when more space is needed. By
combining automatic extension of the undo tablespace with
automatically tuned undo retention, you can ensure that
long-running queries will succeed by guaranteeing the undo required
for such queries.
After the system has stabilized and you are more familiar with
undo space requirements, Oracle recommends that you set the maximum
size of the tablespace to be slightly (10%) more than the current
size of the undo tablespace.
If you have decided on a fixed-size undo tablespace, the Undo
Advisor can help us estimate needed capacity, and you can then
calculate the amount of retention your system will need. You can
access the Undo Advisor through Enterprise Manager or through the
DBMS_ADVISOR package.
The Undo Advisor relies for its analysis on data collected in
the Automatic Workload Repository (AWR). An adjustment to the
collection interval and retention period for AWRstatisticscan
affect the precision and the type of recommendations the advisor
produces.
Undo AdvisorOracle Database provides an Undo Advisor that
provides advice on and helps automate the establishment of your
undo environment. You activate the Undo Advisor by creating an undo
advisor task through the advisor framework. The following example
creates an undo advisor task to evaluate the undo tablespace. The
name of the advisor is 'Undo Advisor'. The analysis is based on AWR
snapshots, which you must specify by setting parameters
START_SNAPSHOT and END_SNAPSHOT.
In the following example, the START_SNAPSHOT is "1" and
END_SNAPSHOT is "2".
DECLARE
tid NUMBER;
tname VARCHAR2(30);
oid NUMBER;
BEGIN
DBMS_ADVISOR.CREATE_TASK('Undo Advisor', tid, tname, 'Undo
Advisor Task');
DBMS_ADVISOR.CREATE_OBJECT(tname,'UNDO_TBS',null, null, null,
'null', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS',
oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', 1);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', 2);
DBMS_ADVISOR.execute_task(tname);
end;
/
Once you have created the advisor task, you can view the output
and recommendations in the Automatic Database Diagnostic Monitor
(ADDM) in Enterprise Manager. This information is also available in
the DBA_ADVISOR_*data dictionary views.
Calculating space requirements for Undo tablespaceYou can
calculate space requirements manually using the following
formula:
Undo Space = UNDO_RETENTION in seconds * undo blocks for each
second + overhead
where:
* Undo Space is the number of undo blocks
* overhead is the small overhead for metadata and based on
extent and file size (DB_BLOCK_SIZE)
As an example, if UNDO_RETENTION is set to 2 hours, and the
transaction rate (UPS) is 200 undo blocks for each second, with a
4K block size, the required undo space is computed as follows:
(2 * 3600 * 200 * 4K) = 5.8GBs
Such computation can be performed by using information in the
V$UNDOSTAT view. In the steady state, you can query the view to
obtain the transaction rate. The overhead figure can also be
obtained from the view.
Managing Undo TablespacesCreating Undo TablespaceThere are two
methods of creating an undo tablespace. The first method creates
the undo tablespace when the CREATE DATABASE statement is issued.
This occurs when you are creating a new database, and the instance
is started in automatic undo management mode (UNDO_MANAGEMENT =
AUTO). The second method is used with an existing database. It uses
the CREATE UNDO TABLESPACE statement.
You cannot create database objects in an undo tablespace. It is
reserved for system-managed undo data.
Oracle Database enables you to create a single-file undo
tablespace.
The following statement illustrates using the UNDO TABLESPACE
clause in a CREATE DATABASE statement. The undo tablespace is named
undotbs_01 and one datafile, is allocated for it.
SQL>CREATE DATABASE ...UNDO TABLESPACE undotbs_01 DATAFILE
'/path/undo01.dbf'RETENTION GUARANTEE;If the undo tablespace cannot
be created successfully during CREATE DATABASE, the entire
operation fails.
The CREATE UNDO TABLESPACE statement is the same as the CREATE
TABLESPACE statement, but the UNDO keyword is specified. The
database determines most of the attributes of the undo tablespace,
but you can specify the DATAFILE clause.
This example creates the undotbs_02 undo tablespace:
SQL>CREATE UNDO TABLESPACE undotbs_02 DATAFILE
'/path/undo02.dbf' SIZE 2M REUSE AUTOEXTEND ONRETENTION
NOGUARANTEE;You can create more than one undo tablespace, but only
one of them can be active at any one time.
Altering Undo TablespaceUndo tablespaces are altered using the
ALTER TABLESPACE statement. However, since most aspects of undo
tablespaces are system managed, you need only be concerned with the
following actions Adding datafile
SQL>ALTER TABLESPACE undotbs ADD DATAFILE
'/path/undo0102.dbf' AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED;
Renaming data file
SQL>ALTER DATABASE RENAME FILE 'old_full_path' TO
'new_full_path'; Resizing datafile
SQL>ALTER DATABASE DATAFILE 'data_file_name|data_file_number'
RESIZE nK|M|G|T|P|E;
when resizing the undo tablespace you may encounter ORA-03297
error: file contains used data beyond the requested RESIZE value.
This means that some undo information stills stored above the
datafile size we want to set. We can check the most high used block
to check the minimum size that we can resize a particular datafile,
by querying the dba_free_space view.Another way to set undo
tablespace to the size that we want is, to create another undo
tablespace, set it the default one, take offline the old and then
just drop the big old tablespace.
Making datafile online or offline
SQL>ALTER TABLESPACE undotbs offline;
SQL>ALTER TABLESPACE undotbs online; Beginning or ending an
open backup on datafile
Enabling and disabling undo retention guarantee
SQL>ALTER TABLESPACE undotbs RETENTION GUARANTEE;
SQL>ALTER TABLESPACE undotbs RETENTION NOGUARANTEE;These are
also the only attributes you are permitted to alter.
If an undo tablespace runs out of space, or you want to prevent
it from doing so, you can add more files to it or resize existing
datafiles.
Dropping Undo TablespaceUse the DROP TABLESPACE statement to
drop an undo tablespace.
SQL>DROP TABLESPACE undotbs_01;An undo tablespace can only be
dropped if it is not currently used by any instance. If the undo
tablespace contains any outstanding transactions (e.g. a
transaction died but has not yet been recovered), the DROP
TABLESPACE statement fails. However, since DROP TABLESPACE drops an
undo tablespace even if it contains unexpired undo information
(within retention period), you must be careful not to drop an undo
tablespace if undo information is needed by some existing
queries.
DROP TABLESPACE for undo tablespaces behaves like DROP
TABLESPACE ... INCLUDING CONTENTS. All contents of the undo
tablespace are removed.
Switching Undo TablespacesYou can switch from using one undo
tablespace to another. Because the UNDO_TABLESPACE initialization
parameter is a dynamic parameter, the ALTER SYSTEM SET statement
can be used to assign a new undo tablespace.
SQL>ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_02;Assuming
undotbs_01 is the current undo tablespace, after this command
successfully executes, the instance uses undotbs_02 in place of
undotbs_01 as its undo tablespace.
If any of the following conditions exist for the tablespace
being switched to, an error is reported and no switching
occurs:
The tablespace does not exist
The tablespace is not an undo tablespace
The tablespace is already being used by another instance (in RAC
environment)
The database is online while the switch operation is performed,
and user transactions can be executed while this command is being
executed. When the switch operation completes successfully, all
transactions started after the switch operation began are assigned
to transaction tables in the new undo tablespace.
The switch operation does not wait for transactions in the old
undo tablespace to commit. If there are any pending transactions in
the old undo tablespace, the old undo tablespace enters into a
PENDING OFFLINE mode. In this mode, existing transactions can
continue to execute, but undo records for new user transactions
cannot be stored in this undo tablespace.
An undo tablespace can exist in this PENDING OFFLINE mode, even
after the switch operation completes successfully. A PENDING
OFFLINE undo tablespace cannot be used by another instance, nor can
it be dropped. Eventually, after all active transactions have
committed, the undo tablespace automatically goes from the PENDING
OFFLINE mode to the OFFLINE mode. From then on, the undo tablespace
is available for other instances (in an RAC environment).
If the parameter value for UNDO TABLESPACE is set to '' (two
single quotes), then the current undo tablespace is switched out
and the next available undo tablespace is switched in. Use this
statement with care, because if there is no undo tablespace
available, the SYSTEM rollback segment is used. This causes
ORA-01552 error to be issued for any attempts to write non-SYSTEM
related undo to the SYSTEM rollback segment.
The following example unassigns the current undo tablespace:
SQL>ALTER SYSTEM SET UNDO_TABLESPACE = '';Establishing User
Quotas for Undo SpaceThe Oracle Database Resource Manager can be
used to establish user quotas for undo space. The Database Resource
Manager directive UNDO_POOL allows DBAs to limit the amount of undo
space consumed by a group of users (resource consumer group).
You can specify an undo pool for each consumer group. An undo
pool controls the amount of total undo that can be generated by a
consumer group. When the total undo generated by a consumer group
exceeds it's undo limit, the current UPDATE transaction generating
the redo is terminated. No other members of the consumer group can
perform further updates until undo space is freed from the
pool.
When no UNDO_POOL directive is explicitly defined, users are
allowed unlimited undo space.
Monitoring Undo TablespacesOracle Database also provides
proactive help in managing tablespace disk space use by alerting
you when tablespaces run low on available space.
In addition to the proactive undo space alerts, Oracle Database
also provides alerts if your system has long-running queries that
cause SNAPSHOT TOO OLD errors. To prevent excessive alerts, the
long query alert is issued at most once every 24 hours. When the
alert is generated, you can check the Undo Advisor Page of
Enterprise Manager to get more information about the undo
tablespace.
The following dynamic performance views are useful for obtaining
space information about the undo tablespace:
ViewDescription
V$UNDOSTATContains statistics for monitoring and tuning undo
space. Use this view to help estimate the amount of undo space
required for the current workload. Oracle uses this view
information to tune undo usage in the system.
V$ROLLSTATFor automatic undo management mode, information
reflects behavior of the undo segments in the undo tablespace.
V$TRANSACTIONContains undo segment information.
DBA_UNDO_EXTENTSShows the status and size of each extent in the
undo tablespace.
WRH$_UNDOSTATContains statistical snapshots of V$UNDOSTAT
information.
WRH$_ROLLSTATContains statistical snapshots of V$ROLLSTAT
information.
To findout the undo segments in the database.
SQL>select segment_name, tablespace_name from
dba_rollback_segs;The V$UNDOSTAT view is useful for monitoring the
effects of transaction execution on undo space in the current
instance. Statistics are available for undo space consumption,
transaction concurrency, the tuning of undo retention, and the
length and SQL ID of long-running queries in the instance. This
view contains information that spans over a 24 hour period and each
row in this view contains data for a 10 minute interval specified
by the BEGIN_TIME and END_TIME.
Each row in the view containsstatisticscollected in the instance
for a 10minute interval. The rows are in descending order by the
BEGIN_TIME column value. Each row belongs to the time interval
marked by (BEGIN_TIME, END_TIME). Each column represents the data
collected for the particular statistic in that time interval. The
first row of the view contains statistics for the (partial) current
time period. The view contains a total of 1008 rows, spanning a 7
day cycle.
FlashbackFeaturesOracle Database includes several features that
are based upon undo information and that allow administrators and
users to access database information from a previous point in time.
These features are part of the overall flashback strategy
incorporated into the database and include:
Flashback Query Flashback Versions Query
Flashback Transaction Query
Flashback Table
Flashback Database
The retention period for undo information is an important factor
for the successful execution of flashback features. It determines
how far back in time a database version can be established.
We must choose an undo retention interval that is long enough to
enable users to construct a snapshot of the database for the oldest
version of the database that they are interested in, e.g. if an
application requires that a version of the database be available
reflecting its content 12 hours previously, then UNDO_RETENTION
must be set to 43200.
You might also want to guarantee that unexpired undo is not
overwritten by specifying the RETENTION GUARANTEE clause for the
undo tablespace.
Migration to Automatic Undo ManagementIf you are still using
rollback segments to manage undo space, Oracle strongly recommends
that you migrate your database to automatic undo management. From
10g, Oracle Database provides a function that provides information
on how to size your new undo tablespace based on the configuration
and usage of the rollback segments in your system. DBA privileges
are required to execute this function:
set serveroutput on
DECLARE
utbsize_in_MB NUMBER;
BEGIN
utbsize_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION;
dbms_output.put_line(utbsize_in_MB||'MB');
END;
/
The function returns the undo tablespace size in MBs.
Best Practices forUndo Tablespace/Undo Management in OracleThis
following list of recommendations will help you manage your undo
space to best advantage.
You need not set a value for the UNDO_RETENTION parameter unless
your system has flashback or LOB retention requirements.
Allow 10 to 20% extra space in your undo tablespace to provide
for some fluctuation in your workload.
Set the warning and critical alert thresholds for the undo
tablespace alert properly.
To tune SQL queries or to check on runaway queries, use the
value of the SQLID column provided in the long query or in the
V$UNDOSTAT or WRH$_UNDOSTAT views to retrieve SQL text and other
details on the SQL from V$SQL view.
Transportable Tablespaces (TTS) in Oracle
We can use the transportable tablespaces feature to copy/move
subset of data (set of user tablespaces), from an Oracle database
and plug it in to another Oracle database. The tablespaces being
transported can be either dictionary managed or locally
managed.
With Oracle 8i, Oracle introduced transportable tablespace (TTS)
technology that moves tablespaces between databases. Oracle 8i
supports tablespace transportation between databases that run on
same OS platforms and use the same database block size.
WithOracle 9i, TTS (Transportable Tablespaces)technology was
enhanced to support tablespace transportation between databases on
platforms of the same type, but using different block sizes.
WithOracle 10g, TTS (Transportable Tablespaces)technology was
further enhanced to support transportation of tablespaces between
databases running on different OS platforms (e.g. Windows to Linux,
Solaris to HP-UX), which has same ENDIAN formats. If ENDIAN formats
are different you have to useRMAN(e.g. Windows to Solaris, Tru64 to
AIX). From this version we can transport whole database, this is
called Transportable Database.
FromOracle 11g, we can transport single partition of a
tablespace between databases.
You can also query the V$TRANSPORTABLE_PLATFORM view to see all
the platforms that are supported, and to determine their platform
names and IDs and their endian format.
SQL> select * from v$transportable_platform order by
platform_id;
PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
----------- ----------------------------------------
--------------
1 Solaris[tm] OE (32-bit) Big
2 Solaris[tm] OE (64-bit) Big
3 HP-UX (64-bit) Big
4 HP-UX IA (64-bit) Big
5 HP Tru64 UNIX Little
6 AIX-Based Systems (64-bit) Big
7 Microsoft Windows IA (32-bit) Little
8 Microsoft Windows IA (64-bit) Little
9 IBM zSeries Based Linux Big
10 Linux IA (32-bit) Little
11 Linux IA (64-bit) Little
12 Microsoft Windows x86 64-bit Little
13 Linux x86 64-bit Little
15 HP Open VMS Little
16 Apple Mac OS Big
17 Solaris Operating System (x86) Little
18 IBM Power Based Linux Big
19 HP IA Open VMS Little
20 Solaris Operating System (x86-64) Little
21 Apple Mac OS (x86-64) Little (from Oracle 11g R2)
To find out your platform name and it's endian format
SQL> select tp.PLATFORM_NAME, tp.ENDIAN_FORMAT from
v$database d, v$transportable_platform tp where
d.platform_name=tp.platform_name;
PLATFORM_NAME ENDIAN_FORMAT
---------------------------------------- --------------
Solaris[tm] OE (64-bit) Big
Transporting tablespaces is particularly useful for
(i) Updating data from production to development and test
instances.
(ii) Updating data from OLTP systems to data warehouse
systems.
(iii) Transportable Tablespace (TTS) is used to take out of the
database pieces of data for various reasons (Archiving, Moving to
other databases etc).
(iv) Performing tablespace point-in-time-recovery (TSPITR).
Moving data using transportable tablespaces can be much faster
than performing either anexport/importor unload/load of the same
data, because transporting a tablespace only requires copying of
datafiles and integrating the tablespace structural information.
You can also use transportable tablespaces to move both table and
index data, thereby avoiding the index rebuilds you would have to
perform when importing or loading table data.
In Oracle 8i, there were three restrictions with TTS. First,
both the databases must have same block size. Second, both
platforms must be the same OS. Third, you cannot rename the
tablespace.Oracle 9iremoves the first restriction.Oracle 10gremoves
the second restriction. Oracle 10g also makes available a command
to rename tablespaces.
Limitations/RestrictionsFollowing are limitations/restrictions
of transportable tablespace:
System, undo, sysaux andtemporary tablespacescannot be
transported.
The source and target database must be on the same hardware
platform. e.g. we can transport tablespaces between Sun Solaris
databases, or we can transport tablespaces between Windows NT
databases. However, you cannot transport a tablespace from a Sun
Solaris database to a Windows NT database.
The source and target database must use the same character set
and national character set.
If Automatic Storage Management (ASM) is used with either the
source or destination database, you must useRMANto
transport/convert the tablespace.
You cannot transport a tablespace to a target database in which
a tablespace with the same name already exists. However, you can
rename either the tablespace to be transported or the destination
tablespace before the transport operation.
Transportable tablespaces do not support:Materialized
views/replication Function-based indexes.
Binary_Float and Binary_Double datatypes (new in Oracle 10g) are
not supported.
At Source:Validating Self Containing PropertyTTS requires all
the tablespaces, which we are moving, must be self contained. This
means that the segments within the migration tablespace set cannot
have dependency to a segment in a tablespace out of the
transportable tablespace set. This can be checked using the
DBMS_TTS.TRANSPORT_SET_CHECK procedure.
SQL> exec DBMS_TTS.TRANSPORT_SET_CHECK('tbs', TRUE);
SQL> exec DBMS_TTS.TRANSPORT_SET_CHECK('tbs1, tbs2, tbs3',
FALSE, TRUE);
SQL> SELECT * FROM transport_set_violations;
No rows should be displayed
If it were not self contained you should either remove the
dependencies by dropping/moving them or include the tablespaces of
segments into TTS set to which migration set is depended.
Put Tablespaces in READ ONLY ModeWe will perform physical file
system copy of tablespace datafiles. In order those datafiles to
not to require recovery, they need to be in consistent during the
copy activity. So put all the tablespaces in READ ONLY mode.
SQL> alter tablespace tbs-name read only;
Export the MetadataExport the metadata of the tablespace
set.
expFILE=/path/dump-file.dmp LOG=/path/tts_exp.log
TABLESPACES=tbs-names TRANSPORT_TABLESPACE=y STATISTICS=none
(or)
expdpDUMPFILE=tts.dmp LOGFILE=tts_exp.log DIRECTORY=exp_dir
TRANSPORT_TABLESPACES=tts TRANSPORT_FULL_CHECK=y
for transporting partition,expdpDUMPFILE=tts_partition.dmp
LOGFILE=tts_partition_exp.log DIRECTORY=exp_dir
TRANSPORTABLE=always TABLES=trans_table:partition_Q1
If the tablespace set being transported is not self-contained,
then the export will fail.
You can drop the tablespaces at source, if you dont want
them.
SQL> drop tablespace tbs-name including contents;
Otherwise, make all the tablespaces as READ WRITE
SQL> alter tablespace tbs-name read write;
Copying Datafiles and export fileCopy the datafiles and export
file to target server.
At Target:Import the export file.
impFILE=/path/dump-file.dmp LOG=/path/tts_imp.log
TTS_OWNERS=user-name FROMUSER=user-name TOUSER=user-name
TABLESPACES=tbs-name TRANSPORT_TABLESPACE=y
DATAFILES=/path/tbs-name.dbf
(or)
impdpDUMPFILE=tts.dmp LOGFILE=tts_imp.log DIRECTORY=exp_dir
REMAP_SCHEMA=master:scott
TRANSPORT_DATAFILES='/path/tts.dbf'
for transporting partition,
impdpDUMPFILE=tts_partition.dmp LOGFILE=tts_partition_imp.log
DIRECTORY=exp_dirTRANSPORT_DATAFILES='/path/tts_part.dbf'
PARTITION_OPTIONS=departition
Finally we have to switch the new tablespaces into read write
mode:
SQL> alter tablespace tbs-name read write;
TRANSPORT TABLESPACEUsingRMAN
Create transportable tablespace sets from backup for one or more
tablespaces.RMAN> TRANSPORT TABLESPACE example, tools TABLESPACE
DESTINATION '/disk1/trans' AUXILIARY DESTINATION '/disk1/aux' UNTIL
TIME 'SYSDATE-15/1440';RMAN> TRANSPORT TABLESPACE exam
TABLESPACE DESTINATION '/disk1/trans' AUXILIARY DESTINATION
'/disk1/aux'DATAPUMPDIRECTORY dpdir DUMP FILE 'dmpfile.dmp' IMPORT
SCRIPT 'impscript.sql' EXPORT LOG 'explog.log';
Using Transportable Tablespaces with a Physical Standby
DatabaseWe can use the Oracle transportable tablespaces feature to
move a subset of an Oracle database and plug it in to another
Oracle database, essentially moving tablespaces between the
databases.
To move or copy a set of tablespaces into a primary database
when a physical standby is being used, perform the following
steps:
1.Generate a transportable tablespace set that consists of
datafiles for the set of tablespaces being transported and an
export file containing structural information for the set of
tablespaces.
2.Transport the tablespace set:
a.Copy the datafiles and the export file to the primary
database.
b.Copy the datafiles to the standby database.The datafiles must
be copied in a directory defined by
theDB_FILE_NAME_CONVERTinitialization parameter.
IfDB_FILE_NAME_CONVERTisnotdefined, then issue theALTER DATABASE
RENAME FILEstatement to modify the standby control fileafterthe
redo data containing the transportable tablespace has been applied
and has failed. TheSTANDBY_FILE_MANAGEMENTinitialization parameter
must be set toAUTO.
3.Plug in the tablespace.Invoke theData Pump utility to plug the
set of tablespaces into the primary database. Redo data will be
generated and applied at the standby site to plug the tablespace
into the standby database.Related PackagesDBMS_TTS
DBMS_EXTENDED_TTS_CHECKS
Temporary Tablespace Group
Temporary Tablespace Groups in OracleOracle 10gintroduced the
concept of temporary tablespace groups.This allows grouping
multipletemporary tablespacesinto a single group and assigning to a
user, this group of tablespaces instead of a single temporary
tablespace.
A tablespace group lets you assign multiple temporary
tablespaces to a single user and increases the addressability of
temporary tablespaces.
A temporary tablespace group has the following properties:
It contains one or more temporary tablespaces (there is no upper
limit).
It contains only temporary tablespaces.
It is not explicitly created. It is created implicitly when the
first temporary tablespace is assigned to it, and is deleted when
the last temporary tablespace is removed from the group.
There is no CREATE TABLESPACE GROUP statement, as implicitly
created during the creation of a temporary tablespace with the
CREATE TEMPORARY TABLESPACE command and by specifying the
TABLESPACE GROUP clause.
Temporary Tablespace Group Benefits It allows multiple default
temporary tablespaces to be specified at the database level.
It allows the user to use multiple temporary tablespaces in
different sessions at the same time.
Reduced contention when multiple temporary tablespaces are
defined.
It allows a single SQL operation to use multiple temporary
tablespaces for sorting.
Finer granularity so you can distribute operations across
temporary tablespaces.
The following statement createstemporary tablespacetemp as a
member of the temp_grp tablespace group. If the tablespace group
does not already exist, then Oracle Database creates it during
execution of this statement.
SQL> CREATE TEMPORARY TABLESPACE tempTEMPFILE 'temp01.dbf'
SIZE 5M AUTOEXTEND ONTABLESPACE GROUP temp_grp;
Adding a temporary tablespace to temporary tablespace group:
SQL> ALTER TEMPORARY TABLESPACE temp TABLESPACE GROUP
temp_grp;
Removing a temporary tablespace from temporary tablespace
group:
SQL> ALTER TEMPORARY TABLESPACE temp TABLESPACE GROUP '';
Assigning temporary tablespace group to a user (same as
assigning temporary tablespace to a user):
SQL> ALTER USER scott TEMPORARY TABLESPACE temp_grp;
Assigning temporary tablespace group as default temporary
tablespace:
SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE
temp_grp;
To see the tablespaces in the temporary tablespace group:
SQL> select * from DBA_TABLESPACE_GROUPS;
Related Views:DBA_TABLESPACE_GROUPS
DBA_TEMP_FILESV$TEMPFILEV$TEMPSTATV$TEMP_SPACE_HEADER
V$TEMPSEG_USAGE
Temporary Tablespace in Oracle
Oracle introduced temporary tablespaces in Oracle 7.3
Temporary tablespacesare used to manage space for database sort
and joining operations and for storing global temporary tables. For
joining two large tables or sorting a bigger result set, Oracle
cannot do in memory by using SORT_AREA_SIZE in PGA (Programmable
Global Area). Space will be allocated in a temporary tablespace for
doing these types of operations. Other SQL operations that might
require disk sorting are: CREATE INDEX, ANALYZE, SELECT DISTINCT,
ORDER BY, GROUP BY, UNION, INTERSECT, MINUS, Sort-Merge joins,
etc.
Note that a temporary tablespace cannot contain permanent
objects and therefore doesn't need to be backed up. A temporary
tablespace contains schema objects only for the duration of a
session.
Creating Temporary Tablespace
From Oracle 9i, we can specify a default temporary tablespace
when you create a database, using the DEFAULT TEMPORARY TABLESPACE
extension to the CREATE DATABASE statement.e.g.SQL> CREATE
DATABASE oracular.....
DEFAULT TEMPORARY TABLESPACE temp_ts.....;
Oracle provides various ways of creating TEMPORARY
tablespaces.
Prior to Oracle 7.3- CREATE TABLESPACE temp DATAFILE ...;
Example:SQL> CREATE TABLESPACE TEMPTBS
DATAFILE'/path/temp.dbf' SIZE 2048M AUTOEXTEND ON NEXT 1M MAXSIZE
UNLIMITEDLOGGING DEFAULT NOCOMPRESS ONLINEEXTENT MANAGEMENT
DICTIONARY;
Oracle 7.3 & 8.0- CREATE TABLESPACE temp DATAFILE ...
TEMPORARY;
Example:SQL> CREATE TABLESPACE TEMPTBS
DATAFILE'/path/temp.dbf' SIZE 2048M AUTOEXTEND ON NEXT 1M MAXSIZE
UNLIMITEDLOGGING DEFAULT NOCOMPRESS ONLINE TEMPORARYEXTENT
MANAGEMENT DICTIONARY;
Oracle 8i and above- CREATE TEMPORARY TABLESPACE temp TEMPFILE
...;Examples:SQL> CREATE TEMPORARY TABLESPACE
TEMPTBSTEMPFILE'/path/temp.dbf' SIZE 1000MAUTOEXTEND ON NEXT 8K
MAXSIZE 1500MEXTENT MANAGEMENT LOCAL UNIFORM SIZE 1MBLOCKSIZE
8K;SQL> CREATE TEMPORARY TABLESPACE
TEMPTBS2TEMPFILE'/path/temp2.dbf' SIZE 1000MAUTOEXTEND OFFEXTENT
MANAGEMENT LOCALBLOCKSIZE 2K;
The MAXSIZE clause will default to UNLIMITED, if no value is
specified.All extents of temporary tablespaces are the same size,
so UNIFORM keyword is optional - if UNIFORM is not defined it will
default to 1 MB.
Example using OMF (Oracle Managed Files):SQL> CREATE
TEMPORARY TABLESPACE temp;
Restrictions:(1) We cannot specify nonstandard block sizes for a
temporary tablespace or if you intend to assign this tablespace as
the temporary tablespace for any users.(2) We cannot specify FORCE
LOGGING for an undo or temporary tablespace.(3) We cannot specify
AUTOALLOCATE for a temporary tablespace.
Tempfiles (Temporary Datafiles)
Unlike normal datafiles, tempfiles are not fully allocated. When
you create a tempfiles, Oracle only writes to the header and last
block of the file. This is why it is much quicker to create a
tempfiles than to create a normal datafile.
Tempfiles are not recorded in the database's control file. This
implies that just recreate them whenever you restore the database,
or after deleting them by accident. You can have different tempfile
configurations between primary and standby databases in dataguard
environment, or configure tempfiles to be local instead of shared
in aRAC environment.
One cannot remove datafiles from a tablespace until you drop the
entire tablespace. However, one can remove a tempfile from a
database. Look at this example:
SQL> alter database tempfile 'tempfile_name' drop including
datafiles;//If the file was created as tempfile
SQL> alter database datafile 'tempfile_name' drop;//If the
file was created as datafile
Dropping temp tablespaceSQL> drop tablespace temp_tbs;SQL>
drop tablespace temp_tbs including contents and datafiles;
If you remove all tempfiles from a temporary tablespace, you may
encounter error:ORA-25153: Temporary Tablespace is Empty.
Use the following statement to add a tempfile to a temporary
tablespace:SQL> ALTER TABLESPACE temp ADD TEMPFILE
'/path/temp01.dbf' SIZE 512mAUTOEXTEND ON NEXT 250m MAXSIZE
UNLIMITED;
Except for adding a tempfile, you cannot use the ALTER
TABLESPACE statement for a locally managed temporary tablespace
(operations like rename, set to read only, recover, etc. will
fail).
Locally managed temporary tablespaces have temporary datafiles
(tempfiles), which are similar to ordinary datafiles except:
You cannot create a tempfile with the ALTER DATABASE
statement.
You cannot rename a tempfile or set it to read-only.
Tempfiles are always set to NOLOGGING mode.
When you create or resize tempfiles, they are not always
guaranteed allocation of disk space for the file size specified. On
certain file systems (like UNIX) disk blocks are allocated not at
file creation or resizing, but before the blocks are accessed.
Tempfile information is shown in the dictionary view
DBA_TEMP_FILES and the dynamic performance view V$TEMPFILE.
Note:This arrangement enables fast tempfile creation and
resizing, however, the disk could run out of space later when the
tempfiles are accessed.
Default Temporary Tablespaces
FromOracle 9i, we can define a default temporary tablespace at
database creation time, or by issuing an "ALTER DATABASE"
statement:SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE
temp;By default, the default temporary tablespace is SYSTEM. Each
database can be assigned one and only one default temporary
tablespace. Using this feature, a temporary tablespace is
automatically assigned to users.The following restrictions apply to
default temporary tablespaces:-DEFAULT TEMPORARY TABLESPACE must be
of type TEMPORARY.-DEFAULT TEMPORARY TABLESPACEcannot be taken
off-line.-DEFAULT TEMPORARY TABLESPACE cannot be dropped until you
create another one.
To see the default temporary tablespace for a database, execute
the following query:SQL> select PROPERTY_NAME,PROPERTY_VALUE
from database_properties where property_name like '%TEMP%';
The DBA should assign a temporary tablespace to each user in the
database to prevent them from allocating sort space in the SYSTEM
tablespace. This can be done with one of the following
commands:
SQL> CREATE USER scott TEMPORARY TABLESPACE temp;SQL>
ALTER USER scott TEMPORARY TABLESPACE temp;
To change a user account to use a non-default temp
tablespaceSQL> ALTER USER user1 SET TEMPORARY TABLESPACE
temp_tbs;
Assigningtemporary tablespace groupas default temporary
tablespace:SQL> ALTER DATABASE DEFAULT TEMPORARY TABLESPACE
temp_grp;
Assigning temporary tablespace group to a user (same as
assigning temporary tablespace to a user):
SQL> ALTER USER scott TEMPORARY TABLESPACE temp_grp;
All new users that are not explicitly assigned a TEMPORARY
TABLESPACE will get the default temporary tablespace as its
TEMPORARY TABLESPACE. Also, when you assign a TEMPORARY tablespace
to a user, Oracle will not change this value next time you change
the default temporary tablespace for the database.
Performance Considerations
Some performance considerations for temporary tablespaces:
Always use temporary tablespaces instead of permanent content
tablespaces for sorting & joining (no logging and uses one
large sort segment to reduce recursive SQL and ST space management
enqueue contention).
Ensure that you create your temporary tablespaces as locally
managed instead of dictionary managed (i.e. use sort space bitmap
instead of sys.fet$ and sys.uet$ for allocating space).
Always use TEMPFILE instead of DATAFILE (reduce backup and
recovery time).
Stripe your temporary tablespaces over multiple disks to
alleviate possible disk contention and to speed-up operations (user
processes can read/write to it directly).
The UNIFORM SIZE must be a multiple of the SORT_AREA_SIZE
parameter.
Monitoring Temporary Tablespaces
Unlike datafiles, tempfiles are not listed in V$DATAFILE and
DBA_DATA_FILES. Use V$TEMPFILE and DBA_TEMP_FILES instead.
SQL> SELECT tablespace_name, file_name, bytes FROM
dba_temp_files WHERE tablespace_name = 'TEMP';TABLESPACE_NAME
FILE_NAME BYTES----------------- --------------------------------
--------------TEMP /../temp01.dbf 11,175,650,000
SQL> select file#, name, round(bytes/(1024*1024),2) "SIZE IN
MB's" from v$tempfile;
One can monitor temporary segments from V$SORT_SEGMENT and
V$SORT_USAGE.
DBA_FREE_SPACE does not record free space for temporary
tablespaces. Use DBA_TEMP_FREE_SPACE or V$TEMP_SPACE_HEADER
instead.
SQL> select TABLESPACE_NAME, BYTES_USED, BYTES_FREE from
V$TEMP_SPACE_HEADER;TABLESPACE_NAME BYTES_USED
BYTES_FREE------------------------------ ----------
----------TEMPTBS 4214226944 80740352
From 11g, we can check free temp space in new view
DBA_TEMP_FREE_SPACE.SQL> select * from DBA_TEMP_FREE_SPACE;
Resizing tempfile
SQL> alter database tempfile temp-name resize integer
K|M|G|T|P|E;SQL> alter database tempfile '/path/temp01.dbf'
resize 1000M;
Resizing temporary tablespace
SQL> alter tablespace temptbs resize 1000M;
Renaming (temporary) tablespace, this is fromOracle 10g
SQL> alter tablespace temp rename to temp2;
InOracle 11g, temporary tablespace or it's tempfiles can be
shrinked, up to specified size.
Shrinking frees as much space as possible while maintaining the
other attributes of the tablespace or temp files. The optional KEEP
clause defines a minimum size for the tablespace or temp file.
SQL>alter tablespace temp-tbs shrink space;SQL>alter
tablespace temp-tbs shrink space keep n{K|M|G|T|P|E};SQL> alter
tablespace temp-tbs shrink tempfile 'tempfile-name';SQL> alter
tablespace temp-tbs shrink tempfile 'tempfile-name' keep
n{K|M|G|T|P|E};
The below script reports temporary tablespace usage (script was
created forOracle9iDatabase). With this script we can monitor the
actual space used in a temporary tablespace and see HWM (High Water
Mark) of the temporary tablespace. The script is designed to run
when there is only one temporary tablespace in the database.
SQL> select sum( u.blocks * blk.block_size)/1024/1024 "MB. in
sort segments", (hwm.max * blk.block_size)/1024/1024 "MB. High
Water Mark"from v$sort_usage u, (select block_size from
dba_tablespaces where contents = 'TEMPORARY') blk, (select
segblk#+blocks max from v$sort_usage where segblk# = (select
max(segblk#) from v$sort_usage) ) hwmgroup by hwm.max *
blk.block_size/1024/1024;
How to reclaim used space
Several methods existed to reclaim the space used for a larger
than normal temporary tablespace.(1)Restartingthe database, if
possible.
(2) The method that exists for all releases of Oracle is, simply
drop and recreate the temporary tablespace back to its original (or
another reasonable) size.(3) If you are using Oracle9i or higher,
drop the large tempfile (which will drop the tempfile from the data
dictionary and the OS file system).
From 11g, while creating global temporary tables, we can specify
TEMPORARY tablespaces.
Related Views:
DBA_TEMP_FILESDBA_DATA_FILESDBA_TABLESPACESDBA_TEMP_FREE_SPACE
(Oracle 11g)
V$TEMPFILEV$TEMP_SPACE_HEADERV$TEMPORARY_LOBSV$TEMPSTAT
V$TEMPSEG_USAGE
Statspack in Oracle
Statspack was introduced inOracle8i.
Statspack is a set of performance monitoring, diagnosis and
reporting utility provided by Oracle. Statspack provides improved
UTLBSTAT/UTLESTAT functionality, as its successor, though the old
BSTAT/ESTAT scripts are still available.
Statspack package is a set of SQL, PL/SQL, and SQL*Plus scripts
that allow the collection, automation, storage, and viewing of
performance data. Statspack stores the performance statistics
permanently in Oracle tables, which can later be used for reporting
and analysis. The data collected can be analyzed using Statspack
reports, which includes an instance health and load summary page,
high resource SQL statements, the traditional wait events and
initialization parameters.
Statspack is a diagnosis tool for instance-wide performance
problems; it also supports application tuning activities by
providing data which identifies high-load SQL statements. Statspack
can be used both proactively to monitor the changing load on a
system, and also reactively to investigate a performance
problem.
Although AWR and ADDM (introduced inOracle 10g) provide better
statistics than STATSPACK, users that are not licensed to use the
Enterprise Manager Diagnostic Pack, should continue to use
Statspack.
Statspack versus UTLBSTAT/UTLESTATThe BSTAT-ESTAT utilities
capture information directly from the Oracle's in-memory structures
and then compare the information from two snapshots in order to
produce an elapsed-time report showing the activity of the
database. If we look inside utlbstat.sql and utlestat.sql, we see
the SQL that samples directly from the v$ views. e.g.
V$SYSSTAT;
SQL>insert into stats$begin_stats select * from
v$sysstat;SQL>insert into stats$end_stats select * from
v$sysstat;Statspack improves on the existing UTLBSTAT/UTLESTAT
performance scripts in the following ways:
Statspack collects more data, including high resource SQL (and
the optimizer execution plans for those statements).
Statspack pre-calculates many ratios useful when performance
tuning, such as cache hit ratios, per transaction and per second
statistics (many of these ratios must be calculated manually when
using BSTAT/ESTAT).
Permanent tables owned by PERFSTAT store performance statistics;
instead of creating/dropping tables each time, data is inserted
into the pre-existing tables. This makes historical data
comparisons easier.
Statspack separates the data collection from the report
generation. Data is collected when a 'snapshot' is taken; viewing
the data collected is in the hands of the performance engineer when
they run the performance report.
Data collection is easy to automate using either dbms_job or an
OS utility.
NOTE: If you choose to run BSTAT/ESTAT in conjunction with
statspack, do not run both as the same user. There is a name
conflict with the STATS$WAITSTAT table.
Installing and Configuring Statspack$ cd
$ORACLE_HOME/rdbms/admin
$ sqlplus "/as sysdba" @spcreate.sql
You will be prompted for the PERFSTAT user's password, default
tablespace, and temporary tablespace.
This will create PERFSTAT user, statspack objects in it and
STATSPACK package.
NOTE:Default tablespace or temporary tablespace must not be
SYSTEM for PERFSTAT user.
The SPCREATE.SQL script runs the following scripts:
SPCUSR.SQL: Creates PERFSTAT user and grants privileges
SPCTAB.SQL: Creates STATSPACK tables
SPCPKG.SQL: Creates STATSPACK package
Check the log files (created in present directory): spcusr.lis,
spctab.lis and spcpkg.lis and ensure that no errors were
encountered during the installation.
To install statspack in batch mode, you must assign values to
the SQL*Plus variables that specify the default and temporary
tablespaces before running SPCREATE.SQL.
DEFAULT_TABLESPACE: For the default tablespace
TEMPORARY_TABLESPACE: For the temporary tablespace
PERFSTAT_PASSWORD: For the PERFSTAT user password
$ sqlplus "/as sysdba"
SQL> define default_tablespace='STATS'
SQL> define temporary_tablespace='TEMP_TBS'
SQL> define perfstat_password='perfstat'
SQL> @?/rdbms/admin/spcreate
When SPCREATE.SQL is run, it does not prompt for the information
provided by the variables.
Taking snapshots of the databaseEach snapshot taken is
identified by a snapshot ID, which is a unique number generated at
the time the snapshot is taken. Each time a new collection is
taken, a new SNAP_ID is generated. The SNAP_ID, along with the
database identifier (DBID) and instance number (INSTANCE_NUMBER),
comprise the unique key for a snapshot. Use of this unique
combination allows storage of multiple instances of an OracleReal
Application Clusters (RAC)database in the same tables.
When a snapshot is executed, the STATSPACK software will sample
from the RAM in-memory structures inside the SGA and transfer the
values into the corresponding STATSPACK tables. Taking such a
snapshot stores the current values for the performance statistics
in the statspack tables. This snapshot can be used as a baseline
for comparison with another snapshot taken at a later time.
$ sqlplus perfstat/perfstat
SQL> exec statspack.snap;
or
SQL> exec statspack.snap(i_snap_level=>10);
instruct statspack to do gather more details in the
snapshot.
SQL> select
name,snap_id,to_char(snap_time,'DD.MM.YYYY:HH24:MI:SS') "Date/Time"
from stats$snapshot,v$database;
Note that in most cases, there is a direct correspondence
between the v$view in the SGA and the corresponding STATSPACK
table.
e.g. the stats$sysstat table is similar to the v$sysstat
view.
Remember to settimed_statistics to truefor the instance.
Statspack will then include important timing information in the
data it collects.
Note: In RAC environment, you must connect to the instance for
which you want to collect data.
Scheduling Snapshots gatheringThere are three methods to
automate/schedule the gathering statspack snapshots/statistics.
SPAUTO.SQL - script can be customized and executed to schedule,
a dbms_job to automate, and the collection of statspack
snapshots.
DBMS_JOB procedure to schedule snapshots (you must set the
initialization parameter JOB_QUEUE_PROCESSES to greater than
0).
BEGIN SYS.DBMS_JOB.SUBMIT (job => 999, what =>
'statspack.snap;', next_date => to_date('17/08/2009
18:00:00','dd/mm/yyyy hh24:mi:ss'), interval =>
'trunc(SYSDATE+1/24,''HH'')', no_parse => FALSE );END;/
Use an OS utility, such as cron.
Statspack reportingThe information captured by a STATSPACK
snapshot has accumulated values. The information from the v$views
collects database information at startup time and continues to add
the values until the instance is shutdown. In order to get a
meaningful elapsed-time report, you must run a STATSPACK report
that compares two snapshots.
After snapshots were taken, you can generate performance
reports.
SQL> connect perfstat/perfstat
SQL> @?/rdbms/admin/spreport.sql
When the report is run, you are prompted for the following:
The beginning snapshot ID
The ending snapshot ID
The name of the report text file to be created
It is not correct to specify begin and end snapshots where the
begin snapshot and end snapshot were taken from different instance
startups. In other words, the instance must not have been shutdown
between the times that the begin and end snapshots were taken.
This is necessary because the database's dynamic performance
tables, which statspack queries to gather the data, reside in
memory. Hence, shutting down the Oracle database resets the values
in the performance tables to 0. Because statspack subtracts the
begin-snapshot statistics from the end-snapshot statistics, end
snapshot will have smaller values than the begin snapshot, the
resulting output is invalid and then the report shows an
appropriate error to indicate this.
To get list of snapshots
SQL> select SNAP_ID, SNAP_TIME from STATS$SNAPSHOT;
To run the report without being prompted, assign values to the
SQL*Plus variables that specify the begin snap ID, the end snap ID,
and the report name before running SPREPORT. The variables are:
BEGIN_SNAP: Specifies the begin snapshot ID
END_SNAP: Specifies the end snapshot ID
REPORT_NAME: Specifies the report output name
SQL> connect perfstat
SQL> define begin_snap=1
SQL> define end_snap=2
SQL> define report_name=batch_run
SQL> @?/rdbms/admin/spreport
When SPREPORT.SQL is run, it does not prompt for the information
provided by the variables.
The statspack package includes two reports.
Run statspack report, SPREPORT.SQL, which is general instance
health report that covers all aspects of instance performance. This
report calculates and prints ratios and differences for all
statistics between the two snapshots, similar to the BSTAT/ESTAT
report.
After examining the instance report, run SQL report,
SPREPSQL.SQL, on a single SQL statement (identified by its hash
value). The SQL report only reports on data relating to the single
SQL statement.
Adjusting Statspack collection level & thresholdThese
parameters are used as thresholds when collecting data on SQL
statements, data is captured on any SQL statements that breach the
specified thresholds.
Statspack has two types of collection options, level and
threshold. The level parameter controls the type of data collected
from Oracle, while the threshold parameter acts as a filter for the
collection of SQL statements into the stats$sql_summary table.
SQL> SELECT * FROM stats$level_description ORDER BY
snap_level;
Level 0Captures general statistics, includingrollback segment,
row cache, buffer pool statistics, SGA, system events, background
events, session events, system statistics, wait statistics, lock
statistics, and latch information.
Level 5 (default)Includes capturing high resource usage SQL
Statements, along with all data captured by lower levels.
Level 6Includes capturing SQL plan and SQL plan usage
information for high resource usage SQL Statements, along with all
data captured by lower levels.
Level 7Captures segment level statistics, including logical and
physical reads, row lock, ITL and buffer busy waits, along with all
data captured by lower levels.
Level 10Includes capturing parent & child latch statistics,
along with all data captured by lower levels.
You can change the default parameters used for taking snapshots
so that they are tailored to the instance's workload.
To temporarily use a snapshot level or threshold that is
different from the instance's default snapshot values, you specify
the required threshold or snapshot level when taking the snapshot.
This value is used only for the immediate snapshot taken; the new
value is not saved as the default.
For example, to take a single level 6 snapshot:
SQL> EXECUTE STATSPACK.SNAP(i_snap_level=>6);
You can save the new value as the instance's default in either
of two ways.
Simply use the appropriate parameter and the new value with the
statspack MODIFY_STATSPACK_PARAMETER or SNAP procedure.
1) You can change the default level of a snapshot with the
STATSPACK.SNAP function. The i_modify_parameter=>'true' changes
the level permanent for all snapshots in the future.
SQL> EXEC STATSPACK.SNAP(i_snap_level=>8,
i_modify_parameter=>'true');
Setting the I_MODIFY_PARAMETER value to TRUE saves the new
thresholds in the STATS$STATSPACK_PARAMETER table. These thresholds
are used for all subsequent snapshots.
If the I_MODIFY_PARAMETER was set to FALSE or omitted, then the
new parameter values are not saved. Only the snapshot taken at that
point uses the specified values. Any subsequent snapshots use the
preexisting values in the STATS$STATSPACK_PARAMETER table.
2) Change the defaults immediately without taking a snapshot,
using the STATSPACK.MODIFY_STATSPACK_PARAMETER procedure. For
example, the following statement changes the snapshot level to 10
and modifies the SQL thresholds for BUFFER_GETS and DISK_READS:
SQL> EXECUTE STATSPACK.MODIFY_STATSPACK_PARAMETER
(i_snap_level=>10, i_buffer_gets_th=>10000,
i_disk_reads_th=>1000);
This procedure changes the values permanently, but does not take
a snapshot.
Snapshot level and threshold information used by the package is
stored in the STATS$STATSPACK_PARAMETER table.
Creating Execution Plan of an SQLWhen you examine the instance
report, if you find high-load SQL statements that you want to
examine more closely or if you have identified one or more
problematic SQL statement, you may want to check the execution
plan. The SQL statement to be reported on is identified by a hash
value, which is a numerical representation of the statement's SQL
text. The hash value for each statement is displayed for each
statement in the SQL sections of the instance report. The SQL
report, SPREPSQL.SQL, displays statistics, the complete SQL text,
and (if level is more than six) information on any SQL plan(s)
associated with that statement.
$ sqlplus perfstat/perfstat
SQL> @?/rdbms/admin/sprepsql.sql
The SPREPSQL.SQL report prompts you for the following:
Beginning snapshot ID
Ending snapshot ID
Hash value for the SQL statement
Name of the report text file