Professional Documents
Culture Documents
Database Admin PDF
Database Admin PDF
3] Resize Datafile
alter database datafile 'd:\ora9i\oradata\test1\test.dbf' resize 50m;
Resize Tempfile
select TABLESPACE_NAME,sum(bytes)/1024/1024 MB from dba_data_files group by
TABLESPACE_NAME
Creating and Managing Index
Btree Bitmap
Suitable for high cardinality column Low cardinality column.
Inefficient for queries using OR Operator efficient for queries using OR Operator
Use for OLTP Use for data warehousing.
RMAN Configuration
1] Set Database in Archivelog Mode.
A] connect sys as sysdba
B] startup mount
C] alter database archivelog
D] alter database open
2] set parameter in init.ora
a] log_archive_start=true
b] log_archive_dest=d:\ora9i\admin\test1\archive
c] log_archive_format=’%t%s.dbf
3] create user rman identified by rman default tablespace tools temporary tablespace temp;
4] grant recovery_catalog_owner,connect,resource to rman;
5] c:\>rman catalog rman/rman
6] rman>create catalog;
7] rman>exit;
8] c:\>rman target system/manager@test catalog rman/rman
9] rman>register database;
10] rman>backup database;
11] shutdown the db
12] delete datafile and startup db
13] datafile error
14] cmd
15] connect rman target system/manager
16] restore database;
17] recover database;
Using RMAN Incomplete Recovery
First you Backup the whole database using rman
1] Mount the database
2] Allocate multiple channel for parallelization
3] Restore all datafiles
4] Recover the database using UNTIL SCN, UNTIL TIME, UNTIL SEQUENCE
5] Open the database using RESETLOGS option
6] Perform Whole Database Backup.
First You have to set this variable in registry in ORACLE_HOME
NLS_LANG=American
NLS_DATE_FORMAT=’YYYY-MM-DD:HH24:MI:SS’
Example:-
1] Shutdown Immediate
2] Startup Mount
3] Open New Command Window
4] c:\>rman target /
5] rman>run{ allocate channel c1 type disk;
allocate channel c2 type disk;
set until time =’2005-09-14 14:21:00’;
restore database;
recover database;
alter database open resetlogs;}
Using RMAN Complete Recovery
1] connect to rman
c:\>rman target /
2] Backup the database
rman>backup database;
3] After completing the backup accidentally your datafile is deleted or copy different location
4] Start database in mount mode
Startup Mount;
5] Open another window
c:\>rman target /
6] restore database;
7] recover database;
8] alter database open;
9] select * from v$datafile;
Your datafile is loss / USER MANAGE RECOVERY
1] Shut down the database
shu immediate;
2] Cut particular datafile from directory and paste it to different location
3] Startup database [it will give error ]
4] Make datafile offline which is not present.
alter database datafile 'D:\ORA9I\ORADATA\TEST1\TEST.DBF' offline;
5] Open the database
alter database open;
6] Make tablespace offline
alter tablespace test offline immediate;
7] recover automatic tablespace test;
[if there are no changes happens with datafile error give]
ORA-00283: recovery session canceled due to errors
ORA-00264: no recovery required
8] Online the tablespace
alter tablespace test online;
9] Online the datafile.
alter database datafile 'D:\ORA9I\ORADATA\TEST1\TEST.DBF' online;
SQL * Loader
1] connect jagat/jagat
2] create table dept (deptno number(2), dname char(14) , loc char(13) ) ;
3] Create dept.ctl file with contents
load data
infile *
into table dept
fields terminated by ‘,’ optionally enclosed by “”
(deptno,dname,loc)
begindata
12,research,”Saratoga”
10,”accounting”,cleveland
11,finance,”boston”
21,”sales”,phila
22,”sales”,Rochester
42,”int’l”,”san fran”
4] c:\>sqlldr control=dept.ctl log=dept.log userid=jagat/jagat
Default Sizing
Log_buffer_size =512k
Shared_pool_size=44m
Sga_max_size=112m
Sort_area_size=512k
db_cache_size=32m
db_block_size=4k
large_pool_size=1m
java_pool_size=32m
STATPACK
1] SQL>create tablespace statpk datafile 'd:\oracle9i\oradata\sonu\statpk.dbf' size 100m;
# Applicable for if before you run this utility
SQL>@d:\oracle9i\ rdbms\admin\spdrop.sql;
2] When you run this script you specify the tablespace name for statpack (i.e statpk) and temporary
tablespace
SQL>@d:\oracle9i\ rdbms\admin\spcreate.sql;
3] SQL>execute statspack.snap;
SQL>execute statspack.snap;
4] when you run this script enter the value for start snap id and end snap id (i.e 1 to 2) and enter report name
which is default store in c drive
5] SQL>@d:\oracle9i\rdbms\admin\spreport.sql
TKPROF
Procedure to enable SQL trace for users on your database:
1. Get the SID and SERIAL# for the process you want to trace.
SQL> select sid, serial# from sys.v_$session where...
SID SERIAL#
---------- ----------
8 13607
2. Enable tracing for your selected process:
SQL> ALTER SYSTEM SET TIMED_STATISTICS = TRUE;
SQL> execute dbms_system.set_sql_trace_in_session(8, 13607, true);
3. Ask user to run just the necessary to demonstrate his problem.
4. Disable tracing for your selected process:
SQL> execute dbms_system.set_sql_trace_in_session (8,13607, false);
SQL> ALTER SYSTEM SET TIMED_STATISTICS = FALSE;
5. Look for trace file in USER_DUMP_DEST
$ cd /app/oracle/admin/oradba/udump
6. Run TKPROF to analyze trace output
$ tkprof d:\ora9i\admin\test1\udump\ora_9294.trc x.txt EXPLAIN=system/manager SYS=NO
7. View or print the output file x.txt
EXPLAIN PLAN
1] Connect to local user
2] sql>set time on
3] execute any sql statement
4] see the time required for the query output
5] sql>@d:\ora9i\rdbms\admin\utlxplan.sql;
6] select * from plan_table; (the table is empty)
7] explain plan for SQL STATEMENT
8] sql>@d:\ora9i\rdbms\admin\utlxplp.sql;
9] if the output of this script is TABLE ACCESS FULL then
Create index on column which is in where clause and execute sql statement
Create index no on y(no) tablespace test_ind;
ANALYZE SCHEMA and TABLES
1] Check the TABLESPACE Name from DBA_TABLESPACE
sql>select tablespace_name from dba_tablespace;
2] if you want to check the table belongs to which tablespace;
sql>select tablespace_name,table_name from dba_tables where owner=’SCOTT’;
3] Move tables
sql>Alter table finance.dt_transaction move tablespace finance
storage(initial 10m next 5m pctincrease 0 maxextents unlimited);
4] execute dbms_utility.analyze_schema(‘FINANCE’,’compute’);
REF CURSOR
Create or replace procdure(p_table in varchar2) as
type t_deptemp is ref cursor;
v_cur t_deptemp;
begin
if p_table=upper(‘emp’) then
open v_cur from select * from emp;
elsif p_table=upper(‘dept’) then
open v_cur from select * from dept;
else
message(‘Cursor unable to Open’);
end if;
end;
Check Database Size
1] select sum(BYTES)/1024/1024/1024 from dba_data_files;
PL/SQL TABLE
DECLARE
TYPE NumList IS TABLE OF NUMBER;
depts NumList := NumList(10, 20, 30, 40);
BEGIN
depts.DELETE(3); -- delete third element
FORALL i IN depts.FIRST..depts.LAST
DELETE FROM emp WHERE deptno = depts(i); -- causes an error
END;
-- Now we can see the statments that triggered the auditing condition...
select sqltext from sys.fga_log$;
delete from sys.fga_log$;
2] How dose one switch to another user in Oracle
1] Sql>select password from dba_users where username=’SCOTT’
PASSWORD
----------------
F894844C34402B67
2] SQL>alter user scott identified by lion;
User altered
3] Connect scott/lion
4] Do whatever you like
5] connect system/manager
6] alter user scott identified by values ‘F894844C34402B67’
7] connect scott/tiger
There is no single system table which contains the high water mark (HWM) for a table. A table's HWM
can be calculated using the results from the following SQL statements:
SELECT BLOCKS FROM DBA_SEGMENTS WHERE OWNER=UPPER(owner) AND
SEGMENT_NAME = UPPER(table);
4. Bring the tablespace online. For example, the following statement brings tablespace users back online:
5. ALTER TABLESPACE users ONLINE;
6. After you bring a tablespace online, it is open and available for use.
5. Archive the unarchived redo logs so that the redo required to recover the tablespace backup is archived.
For example, enter:
6. ALTER SYSTEM ARCHIVE LOG CURRENT;
Making User-Managed Backups of Online Tablespaces and Datafiles
You can back up all or only specific datafiles of an online tablespace while the database is open. The procedure
differs depending on whether the online tablespace is read/write or read-only.
This section contains these topics:
• Making User-Managed Backups of Online Read/Write Tablespaces
• Making Multiple User-Managed Backups of Online Read/Write Tablespaces
• Ending a Backup After an Instance Failure or SHUTDOWN ABORT
• Making User-Managed Backups of Read-Only Tablespaces
• Making User-Managed Backups of Undo Tablespaces
3. Back up the online datafiles of the online tablespace with operating system commands. For example,
UNIX users might enter:
4. % cp /oracle/dbs/tbs_21.f /oracle/backup/tbs_21.backup
5. % cp /oracle/dbs/tbs_22.f /oracle/backup/tbs_22.backup
6.
4. After backing up the datafiles of the online tablespace, indicate the end of the online backup by using the
SQL statement ALTER TABLESPACE with the END BACKUP option. For example, the following statement
ends the online backup of the tablespace users:
5. SQL> ALTER TABLESPACE users END BACKUP;
6.
5. Archive the unarchived redo logs so that the redo required to recover the tablespace backup is archived.
For example, enter:
6. SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Making Multiple User-Managed Backups of Online Read/Write Tablespaces
When backing up several online tablespaces, you can back them up either serially or in parallel. Use either of the
following procedures depending on your needs.
You can simultaneously put all tablespaces requiring backups in backup mode. Note that online redo logs can
grow large if multiple users are updating these tablespaces because the redo must contain a copy of each changed
data block.
To back up online tablespaces in parallel:
1. Prepare all online tablespaces for backup by issuing all necessary ALTER TABLESPACE statements at once.
For example, put tablespaces ts1, ts2, and ts3 in backup mode as follows:
2. SQL> ALTER TABLESPACE ts1 BEGIN BACKUP;
3. SQL> ALTER TABLESPACE ts2 BEGIN BACKUP;
4. SQL> ALTER TABLESPACE ts3 BEGIN BACKUP;
5.
2. Back up all files of the online tablespaces. For example, a UNIX user might back up datafiles with the
tbs_ prefix as follows:
3. % cp /oracle/dbs/tbs_* /oracle/backup
4.
4. Archive the unarchived redo logs so that the redo required to recover the tablespace backups is archived.
For example, enter:
5. SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Backing Up Online Tablespaces Serially
You can place all tablespaces requiring online backups in backup mode one at a time. Oracle Corporation
recommends the serial backup option because it minimizes the time between ALTER TABLESPACE ... BEGIN/END
BACKUP statements. During online backups, more redo information is generated for the tablespace because whole
data blocks are copied into the redo log.
To back up online tablespaces serially:
1. Prepare a tablespace for online backup. For example, to put tablespace tbs_1 in backup mode enter the
following:
2. SQL> ALTER TABLESPACE tbs_1 BEGIN BACKUP;
3.
4. Repeat this procedure for each remaining tablespace until you have backed up all the desired tablespaces.
5. Archive the unarchived redo logs so that the redo required to recover the tablespace backups is archived.
For example, enter:
6. SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Ending a Backup After an Instance Failure or SHUTDOWN ABORT
This section contains these topics:
• About Instance Failures When Tablespaces are in Backup Mode
• Ending Backup Mode with the ALTER DATABASE END BACKUP Statement
• Ending Backup Mode with the RECOVER Command
The following situations can cause a tablespace backup to fail and be incomplete:
• The backup completed, but you did not indicate the end of the online tablespace backup operation with
the ALTER TABLESPACE ... END BACKUP statement.
• An instance failure or SHUTDOWN ABORT interrupted the backup before you could complete it.
Whenever crash recovery is required (not instance recovery, because in this case the datafiles are open already),
if a datafile is in backup mode when an attempt is made to open it, then the system assumes that the file is a
restored backup. Oracle will not open the database until either a recovery command is issued, or the datafile is
taken out of backup mode.
For example, Oracle may display a message such as the following when you run the STARTUP statement:
ORA-01113: file 12 needs media recovery
ORA-01110: data file 12: '/oracle/dbs/tbs_41.f'
If Oracle indicates that the datafiles for multiple tablespaces require media recovery because you forgot to end
the online backups for these tablespaces, then so long as the database is mounted, running the ALTER DATABASE
END BACKUP statement takes all the datafiles out of backup mode simultaneously.
In high availability situations, and in situations when no DBA is monitoring the database (for example, in the
early morning hours), the requirement for user intervention is intolerable. Hence, you can write a crash recovery
script that does the following:
1. Mounts the database
2. Runs the ALTER DATABASE END BACKUP statement
An automated crash recovery script containing ALTER DATABASE END BACKUP is especially useful in the following
situations:
• All nodes in an Oracle Real Application Clusters configuration fail.
• One node fails in a cold failover cluster (that is, a cluster that is not an Oracle Real Application Cluster
in which the secondary node must mount and recover the database when the first node fails).
Alternatively, you can take the following manual measures after the system fails with tablespaces in backup
mode:
• Recover the database and avoid issuing END BACKUP statements altogether.
• Mount the database, then run ALTER TABLESPACE ... END BACKUP for each tablespace still in backup
mode.
Ending Backup Mode with the ALTER DATABASE END BACKUP Statement
You can run the ALTER DATABASE END BACKUP statement when you have multiple tablespaces still in backup
mode. The primary purpose of this command is to allow a crash recovery script to restart a failed system without
DBA intervention. You can also perform the following procedure manually.
To take tablespaces out of backup mode simultaneously:
1. Mount but do not open the database. For example, enter:
2. SQL> STARTUP MOUNT
3.
2. If performing this procedure manually (that is, not as part of a crash recovery script), query the V$BACKUP
view to list the datafiles of the tablespaces that were being backed up before the database was restarted:
3. SQL> SELECT * FROM V$BACKUP WHERE STATUS = 'ACTIVE';
4. FILE# STATUS CHANGE# TIME
5. ---------- ------------------ ---------- ---------
6. 12 ACTIVE 20863 25-NOV-00
7. 13 ACTIVE 20863 25-NOV-00
8. 20 ACTIVE 20863 25-NOV-00
9. 3 rows selected.
10.
3. Issue the ALTER DATABASE END BACKUP statement to take all datafiles currently in backup mode out of
backup mode. For example, enter:
4. SQL> ALTER DATABASE END BACKUP;
5.
You can use this statement only when the database is mounted but not open. If the
database is open, use ALTER TABLESPACE ... END BACKUP or ALTER DATABASE DATAFILE ...
END BACKUP for each affected tablespace or datafile.
The ALTER DATABASE END BACKUP statement is not the only way to respond to a failed online backup: you can
also run the RECOVER command. This method is useful when you are not sure whether someone has restored a
backup, because if someone has indeed restored a backup, then the RECOVER command brings the backup up to
date. Only run the ALTER DATABASE END BACKUP or ALTER TABLESPACE ... END BACKUP statement if you are sure
that the files are current.
To take tablespaces out of backup mode with the RECOVER command:
1. Mount the database. For example, enter:
2. SQL> STARTUP MOUNT
3.
3. Use the V$BACKUP view to confirm that there are no active datafiles:
4. SQL> SELECT * FROM V$BACKUP WHERE STATUS = 'ACTIVE';
5. FILE# STATUS CHANGE# TIME
6. ---------- ------------------ ---------- ---------
7. 0 rows selected.
Making User-Managed Backups of Read-Only Tablespaces
When backing up an online read-only tablespace, you can simply back up the online datafiles. You do not have
to place the tablespace in backup mode because the system is permitting changes to the datafiles.
If the set of read-only tablespaces is self-contained, then in addition to backing up the tablespaces with operating
system commands, you can also export the tablespace metadata by using the transportable tablespace
functionality. In the event of a media error or a user error (such as accidentally dropping a table in the read-only
tablespace), you can transport the tablespace back into the database.
To back up online read-only tablespaces in an open database:
1. Query the DBA_TABLESPACES view to determine which tablespaces are read-only. For example, run this
query:
2. SELECT TABLESPACE_NAME, STATUS
3. FROM DBA_TABLESPACES
4. WHERE STATUS = 'READ ONLY';
5.
2. Before beginning a backup of a read-only tablespace, identify all of the tablespace's datafiles by querying
the DBA_DATA_FILES data dictionary view. For example, assume that you want to back up the history
tablespace. Enter the following:
3. SELECT TABLESPACE_NAME, FILE_NAME
4. FROM SYS.DBA_DATA_FILES
5. WHERE TABLESPACE_NAME = 'HISTORY';
6.
7. TABLESPACE_NAME FILE_NAME
8. ------------------------------- --------------------
9. HISTORY /oracle/dbs/tbs_hist1.f
10. HISTORY /oracle/dbs/tbs_hist2.f
11.
In this example, /oracle/dbs/tbs_hist1.f and /oracle/dbs/tbs_hist2.f are fully
specified filenames corresponding to the datafiles of the history tablespace.
3. Back up the online datafiles of the read-only tablespace with operating system commands. You do not
have to take the tablespace offline or put the tablespace in backup mode because users are automatically
prevented from making changes to the read-only tablespace. For example, UNIX users can enter:
4. % cp /oracle/dbs/tbs_hist*.f /backup
4. Optionally, export the metadata in the read-only tablespace. By using the transportable tablespace feature,
you can quickly restore the datafiles and import the metadata in case of media failure or user error. For
example, export the metadata for tablespace history as follows:
5. % exp TRANSPORT_TABLESPACE=y TABLESPACES=(history) FILE=/oracle/backup/tbs_hist.dmp
Making User-Managed Backups of Undo Tablespaces
In releases prior to Oracle9i, undo space management was based on rollback segments. This method is called
manual undo management mode. In Oracle9i, you have the option of placing the database in automatic undo
management mode. With this design, you allocate undo space in a single undo tablespace instead of distributing
space into a set of statically allocated rollback segments.
The procedures for backing up undo tablespaces are exactly the same as for backing up any other read/write
tablespace. Because the automatic undo tablespace is so important for recovery and for read consistency, you
should back it up frequently as you would for tablespaces containing rollback segments when running in manual
undo management mode.
If the datafiles in the undo tablespace were lost while the database was open, and you did not have a backup, you
could receive error messages when querying objects containing uncommitted changes. Also, if an instance
failure occurred, you would not be able to roll back uncommitted transactions to their original values.
Making User-Managed Backups in SUSPEND Mode
This section contains the following topics:
• About the Suspend/Resume Feature
• Making Backups in a Suspended Database
Temporary Tablespace
To see the datafile belongs to temporary tablespace.
select * from DBA_TEMP_FILES;
ANALYZE
select * from v$librarycache;
select sum(pins) "exe",sum(reloads) "cache Miss",sum(reloads)/sum(pins) from v$librarycache;
select count(*) from jagat.y;
select namespace,pins,reloads,invalidations from v$librarycache;
analyze table jagat.y compute statistics;
select count(*) from jagat.y;
select namespace,pins,reloads,invalidations from v$librarycache;
Recovery Steps
1] Restored all datafiles.
2] Redo Applied
3] Database Containing Uncommitted and commited transaction.
4] Undo applied
5] Recover Database.
User Managed Recovery in NoArchiveLog Mode
1] Shutdown Abort
2] Copy all Datafiles from backup to Oradata Directory
3] Connect as sysdba
4] Startup
Recovery in Noarchivelog mode without redo log file Backup.
1] Shutdown the Instance.
Shutdown Immediate;
2] Restore the Datafiles and Control file from most resent whole Database Backup.
Copy All Datafiles and Control File
3] Perform Cancel Based Recovery
Recover Database Until Cancel
4] Open Database with Resetlog Mode.
Alter Database Open Resetlogs;
Recovery in Archive Log Mode :-Advantage and Disadvantages
Advantage
1] Need to restore only lost or damaged file only.
2] No committed data is lost.
3] Recovery can be performed while the database is Open(except system tablespace files and datafiles
that contain online rollback segment)
DisAdvantage
1] You must have all the Archive Redo log files from the time your last backup.if you missing one
you cannot perform complete recovery. Because all Archive file applied in sequence.
Close Database Recovery
1] Shutdown Abort;
2] Copy All Datafiles.
3] Startup Mount
4] Recover Database; or Recover Datafile ‘<PATH>’;
5] Alter Database Open;
Open Database Recovery
1] if the datafile 2 is online then Take the datafile 2 offline
2] Restore datafile 2 from Backup.
3] Recover Datafile <path of Datafile> or
Recover Tablespace < Tablespace Name Datafile belongs to that>
4] Alter database datafile <path> online; or
Alter tablespace <Tablespace Name Datafile belongs to that>;
Recovery Without Backup Datafile
1] Mount the Database
Startup Mount;
2] Offline the Tablespace
Alter tablespace table_data offline immediate;
3] Select * from V$recover_file;
4] Alter Database create Datafile ‘/disk2/data/df04.dbf’ as ‘/disk4/data/df04.dbf’
5] Select * from V$recover_file;
6] Recover Tablespace Table_data; or
Alter Database recover Tablespace Table_data
7] Alter Tablespace table_data online;
Using RMAN Recover Database in NoArchive Log Mode
1] rman target /
2] startup mount
3] Restore Database;
4] Recover Database;
5] Alter Database Open Resetlogs;
Using RMAN to Restore Datafiles to New Location
1] Rman Target /
2] Startup Mount;
3] Run{ set new name for datafile 1 to ‘/<newdir>/system.dbf’
Restore Database;
Switch Datafile all;
Recover Database;
Alter Database Open;}
Using Rman Recover Tablespace
1] Run{ Sql “Alter Tablespace users offline immediate;
Restore Tablespace Users;
Recover Tablespace Users;
Sql “Alter tablespace Users Online”; }
Using Rman Relocate Tablespace
1] Run{ Sql “Alter Tablespace Users Offline Immediate”;
Set Newname for datafile ‘/oradata/u03/users01.dbf’ to ‘/oradata/u04/users01.dbf’;
Restore (tablespace Users);
Switch Datafile 3;
Recover Tablespace Users;
Sql “Alter Tablespace tbs online”;}
Script Example
1] Create script Level0Backup {
backup
incremental level 0
format ‘/u01/db1/backup/%d_%s_%p’
fileperset 5
(database include current controlfile);
sql ‘alter database archive log current’;}
2] To Execute This Script
RMAN>run {execute script Level0Backup;}
EXPORT
1] Direct=Y
You can extract data much faster. Export utility reads directly from data layer instated of going through
the SQL-Command processing Layer.
Example:- Exp userid=system/manager file=exp_dir.dmp full=y direct=y;
Restriction
A] Client-side and Server-side Character sets must be same.
B] You cannot use the Direct Path option to export rows containing LOB, BFILE, REF
or object types.
CONSISTENT=Y Default: n
Specifies whether or not Export uses the SET TRANSACTION READ ONLY statement to ensure that the data
seen by Export is consistent to a single point in time and does not change during the execution of the exp
command. You should specify CONSISTENT=y when you anticipate that other applications will be updating the
target data after an export has started.
If you use CONSISTENT=n, each table is usually exported in a single transaction. However, if a table contains
nested tables, the outer table and each inner table are exported as separate transactions. If a table is partitioned,
each partition is exported as a separate transaction.
Therefore, if nested tables and partitioned tables are being updated by other applications, the data that is exported
could be inconsistent. To minimize this possibility, export those tables at a time when updates are not being
done.
If the export uses CONSISTENT=y, none of the updates by user2 are written to the export file.
If the export uses CONSISTENT=n, the updates to TAB:P1 are not written to the export file. However, the
updates to TAB:P2 are written to the export file because the update transaction is committed before the export of
TAB:P2 begins. As a result, the user2 transaction is only partially recorded in the export file, making it
inconsistent.
If you use CONSISTENT=y and the volume of updates is large, the rollback segment usage will be large. In
addition, the export of each table will be slower because the rollback segment must be scanned for uncommitted
transactions.
Keep in mind the following points about using CONSISTENT=y:
CONSISTENT=y is unsupported for exports that are performed when you are connected as user SYS or you are
using AS SYSDBA, or both.
Export of certain metadata may require the use of the SYS schema within recursive SQL. In such situations, the
use of CONSISTENT=y will be ignored. Oracle Corporation recommends that you avoid making metadata
changes during an export process in which CONSISTENT=y is selected.
To minimize the time and space required for such exports, you should export tables that need to remain
consistent separately from those that do not.
For example, export the emp and dept tables together in a consistent export, and then export the remainder of the
database in a second pass.
A "snapshot too old" error occurs when rollback space is used up, and space taken up by committed transactions
is reused for new transactions. Reusing space in the rollback segment allows database integrity to be preserved
with minimum space requirements, but it imposes a limit on the amount of time that a read-consistent image can
be preserved.
If a committed transaction has been overwritten and the information is needed for a read-consistent view of the
database, a "snapshot too old" error results.
To avoid this error, you should minimize the time taken by a read-consistent export. (Do this by restricting the
number of objects exported and, if possible, by reducing the database transaction rate.) Also, make the rollback
segment as large as possible.
Row Migration
Oracle will try to shift the entire row from the current block to another block having 25 (10+15) units of free
space. However, it will not remove all the relevant entries for that row from the old block. It will store the new
block row ID into the old block.
Now, if I want to view that record, Oracle will internally first check the old block and then from there it will get
the new row ID and display the row data from the new block. With this extra amount of I/O operation required,
you likely have guessed correctly that it would degrade the performance.
Now the first question that you might ask is what is the use of maintaining the old row ID if the entire row data
has been migrated from the old block to the new one? This is because of Oracle's internal mechanism -- for the
entire lifespan of a row data, its row ID will never change. That's why Oracle has to maintain two row IDs -- one
is because of Oracle's internal mechanism and one is for the current location of the data.
Row Chaining
What we have discussed to this point is the case where we have data in the block and new insertion is not
possible into that block, which leads Oracle to go ahead and use a new block.
So what happens when a row is so large that it cannot fit into one free block? In this case, Oracle will span the
data into a number of blocks so that it can hold all of the data. The existence of such data results in "Row
Chaining".
Row Chaining is the storage of data in a chain of blocks. This primarily occurs in the lob, clob, blob or big
varchar2 data types.
A temporary solution (since it will only take care of the existing migrated rows and not the future ones) is to
delete the migrated row from the table and perform the insert again. To do this follow these steps:
Analyze the table to get the row ID
Copy those rows to a temporary table
Delete the rows from the original table
Insert the rows from step 2 back to the original table
Avoiding row chaining is very difficult since it is generally caused by insert operations using large data types (i.e
lob, etc.). A good precaution is to either use a large block size (which can't be changed without creating a new
database) or use a large extent size.
To summarize what we have discussed:
Row migration (RM) is typically caused by UPDATE operations.
Row chaining (RC) is typically caused by INSERT operations.
SQL statements which are creating/querying these RM/RC data will degrade the performance due to more I/O
work.
To diagnose this, use the ANALYZE command, query V$SYSSTAT view, or generate a report.txt file
To remove RM, use a higher PCTFREE value.
Share Pool
Library Cache
If the size of Shared pool is too small then SQL Statement continue reload in Library Cache. Which affect the
Performance? Using v$librarycache view you can check the reload if the is non zero then increase the size of
Share Pool.
Consists of most recently SQL/PLSQL Statement.
I] Shared SQL
II] Shared PLSQL.
Data Dictionary Cache
If the size of Data Dictionary Cache is too small, then the database has to query the data dictionary table
repeatedly for information needed by the database. These queries are called recursive calls it affect the
performance. It include the information about Database files, Indexs,Tables,Column, Users, Privileges.
-Consists of Independence Cache
DB_CACHE_SIZE
DB_KEEP_CACHE_SIZE
DB_RECYCLE_CACHE_SIZE
--DB_CACHE_ADVICE can be set to gather static from different cache size. This
parameter have three values(ON,OFF,READY)
ON:-Advisory is turn on and both CPU and memory overhead is incurred.
OFF:- Advisory is off and the memory for advisory is not allocated.
READY:- Advisory is turn off but memory for the advisory remain allocated.
--View :-V$DB_CACHE_ADVICE
Database Buffer Cache
Database Buffer Cache stores the copies of data block that have been retrieved from Data files. Its manage
through the LRU algorithm.
When query is processed Oracle Server process looks in the Database Buffer Cache for any blocks it needs. If
the Block not found in Database Buffer Cache, Server process reads block from data file and place the copy in
Database Buffer Cache, Because subsequent request for the same block may find the block in memory, the
request may not required Physical Read.
Database Buffer Cache can be dynamically resized using
ALTER SYSTEM SET DB_CACHE_SIZE=96m;
Redo Log Buffer
Primary purpose is recovery.
Changes recorded within are called redo entries.
Size define by Log buffer.
Large Pool
The Large Pool optional area of memory in SGA configured only in the Shared Server environment.
When users connect through the Shared Server Oracle needs to allocate additional space in the Shared Pool for
storing information about the connection between the User process, Dispatcher and Servers. The Large Pool
relieves the burden of Shared Pool.
A] This Configured for Backup and Restore,UGA,I/O.
B] Large Pool does not used LRU list.
C] Sized by Large_pool_size
ALTER SYSTEM SET LARGE_POOL_SIZE=64M;
Java Pool
Required if installing and using Java.
Size by Java_pool_size.
PGA
Memory reserved for each user process that connects to oracle database.
AlertSID.log File
--Its default location is Specify in BACKGROUND_DUMP_DEST.
--Keep Following Records.
---When the database was started or shutdown.
---List of non-default initialization parameter.
---The startup of background processes.
---The Thread being used by an instance.
---The log sequence no LGWR is written to.
---Information regarding to log switch.
---Creation of tablespace and undo segments.
---Alter statement that have been issued.
---Information regarding ORA-600
Enabling and disabling Tracing
Session Level:
ALTER SESSION SET SQL_TRACE=’TRUE’;
OR
dbms_system.SET_SQL_TRACE_IN_SESSION
Instance Level
By setting the init.ora file SQL_TRACE=TRUE
Control File
The control file is the binary file define the current State of Physical Database.
Loss of Control file required recovery
Is read at mount Stage.
Is linked to single Database.
Should be multiplexed.
Maintains integrity of database.
Size initially by CREATE DATABSE
(Maxlogfiles,Maxlogmembers,Maxloghistory,Maxdatafiles,Maxinstance)
Control File Contains
Database name and identifier
Time stamp of database creation
Tablespace name
Name and location of Datafile and Redo log file.
Current Redo log file sequence no.
Checkpoint information.
Begin and end of Undo Segment.
Redo log Archive information
Backup information.
View V$controlfile, V$controlfile_Record_Section, V$parameter.
Redo Log File
Redo log files are organized into groups.
An Oracle database required at least two groups.
Each redo log within group called member.
Work
Redo log work in cyclic fashion
When the redo log file is full LGWR will move to next log group.
-This is called log switch.
-Checkpoint operation also occurs.
-Information is written to the control file.
Checkpoint
At every log switch
When an instance shutdown Normal, Transactional, Immediate.
When forced by setting by initialization parameter FAST_START_MTTR_TARGET.
When manually request by DBA {Alter system Checkpoint]
When the ALTER TABLESPACE{BEGIN BACKUP|OFFLINE NORMAL|READ ONLY}
What is the difference between DBFile Sequential and Scattered Reads?
Both "db file sequential read" and "db file scattered read" events signify time waited for I/O read requests to
complete. Time is reported in 100's of a second for Oracle 8i releases and below, and 1000's of a second for
Oracle 9i and above. Most people confuse these events with each other as they think of how data is read from
disk. Instead they should think of how data is read into the SGA buffer cache.
db file sequential read:
A sequential read operation reads data into contiguous memory (usually a single-block read with p3=1, but can
be multiple blocks). Single block I/Os are usually the result of using indexes. This event is also used for
rebuilding the control file and reading datafile headers (P2=1). In general, this event is indicative of disk
contention on index reads.
db file scattered read:
Similar to db file sequential reads, except that the session is reading multiple data blocks and scatters them into
different discontinuous buffers in the SGA. This statistic is NORMALLY indicating disk contention on full table
scans. Rarely, data from full table scans could be fitted into a contiguous buffer area, these waits would then
show up as sequential reads instead of scattered reads.
The following query shows average wait time for sequential versus scattered reads:
prompt "AVERAGE WAIT TIME FOR READ REQUESTS"
select a.average_wait "SEQ READ", b.average_wait "SCAT READ"
from sys.v_$system_event a, sys.v_$system_event b
where a.event = 'db file sequential read'
and b.event = 'db file scattered read';
How Export One user and Drop the Existing and Creating New One.
Take the export of Schema1
Using:
alter table employee modify ( year default to_char(sysdate,'YYYY'), country default 'Pakistan' ) ;
However, AIX UNIX does not use semaphores, and a post/wait driver is
used instead to serialize tasks.
42)Explain an ORA-01555 - You get this error when you get a snapshot
too old within rollback. It can usually be solved by
increasing the undo retention or increasing the size of rollbacks.
You should also look at the logic involved in the
application getting the error message.
automatic undo management allows the DBA to specify how long undo
information should be retained after commit, preventing "snapshot too
old" errors on long running queries.
3)Why Becos after nomount stage of stanby server we have to mount as standby server.
4)Installation of oracle on solaris platform witch file you have to modified first?
/etc/system for configuration of kernel
5)If your database is hanged and you can't connect thro' sqlplus
how can you shutdown database?
ipcs -s|grep $ORACLE_SID gives us semaphore segment set process id
and we
can kill them with the ipcrm commands.
10)When you performed only one datafile recovery that time what u used resetlogs or norestlogs?
That is also part of the complite recovery we have to used the norestlogs
11)But if you are issued the resetlogs then what you after it?
Once resetlogs issued after that we have to take full cold backup.
12)If our buffer cache hit ratio is 90% but system is going to slow how you
can judge that buffer cache is too small?
from the v$waitstat in the data block contention.
17)which file you have to modified when you intersted to set oracle instance automaticaly started?
/etc/oratab
22)how you can fast process the import which has large index?
to set sort_area_size more
32)Suppose one of the your end user come to you and told you that his report is hanged what should you do?
33)If you database is in no archivelog mode and you took backup yesterday and your database size is 40gb very
next day when you start database that time it gives error that one of the redolog file corrupted how can you
recovered it?
35)when data block buffer has too many contention what to do?
38)what is the row chaining and row migration? How can you judged it and tune it?
39)if your database size is more than the 100gb and running 24*7*365 how planned to decide to take backup?
42)if you got ora-1555 error snapshot too old what to do?
43)If you give proper hint in sql query but when you check from the trace that hint is not working why?
kind regards.
3)Why Becos after nomount stage of stanby server we have to mount as standby server.
4)Installation of oracle on solaris platform witch file you have to modified first?
/etc/system for configuration of kernel
5)If your database is hanged and you can't connect thro' sqlplus how can you shutdown database?
ipcs -s|grep $ORACLE_SID gives us semaphore segment set process id and we can kill them with the ipcrm
commands.
10)When you performed only one datafile recovery that time what u used resetlogs or norestlogs?
That is also part of the complite recovery we have to used the norestlogs
11)But if you are issued the resetlogs then what you after it?
Once resetlogs issued after that we have to take full cold backup.
12)If our buffer cache hit ratio is 90% but system is going to slow how you can judge that buffer cache is too
small?
from the v$waitstat in the data block contention.
17)which file you have to modified when you intersted to set oracle instance automaticaly started?
/etc/oratab
22)how you can fast process the import which has large index?
to set sort_area_size more
33)If you database is in no archivelog mode and you took backup yesterday and your database size is 40gb very
next day when you start database that time it gives error that one of the redolog file corrupted how can you
recovered it?
34)What is the buffer busy wait?
35)when data block buffer has too many contention what to do?
38)what is the row chaining and row migration? How can you judged it and tune it?
39)if your database size is more than the 100gb and running 24*7*365 how planned to decide to take backup?
42)if you got ora-1555 error snapshot too old what to do?
43)If you give proper hint in sql query but when you check from the trace that hint is not working why?
Today's 24/7 e-world demands that business data be highly available. Oracle Data Guard is a built-in component of Oracle9i Database
that protects your database from unforeseen disasters, data corruption, and user errors. It also reduces planned downtime and allows
you to provide additional data access for reporting.
Known in earlier database releases as the standby option, the feature now called Oracle Data Guard has long been a dependable and
cost-effective method for achieving high availability and disaster-recovery protection.
This article looks at Oracle Data Guard features and processes both old and new:
• The physical-standby database is a longstanding but invaluable feature that is straightforward to set up and maintain.
• The logical-standby database is new in Oracle9i Database Release 2, and this type of standby provides additional availability
beyond that of the physical-standby database.
• Archive-gap management adds automation to keep primary and standby databases in sync.
Physical-Standby Database
The tried-and-true workhorse of Oracle Data Guard is the physical-standby database, an identical copy, down to the block level, of your
primary database. Usually, the physical-standby database resides on a different server than your primary database. In Oracle9i
Database, Data Guard is typically implemented in managed-recovery mode. This means Oracle processes automatically handle copying
and application of archive redo to the standby database.
Setting up a managed-recovery physical-standby database is fairly straightforward. When getting started with the Oracle Data Guard
setup, it's easiest to implement a physical-standby database if you:
• Set up Oracle Data Guard on two servers: the primary and the standby.
• Ensure that the mount points and directories are named the same for each of the servers.
• Make the database name the same for the primary and standby.
This way, all you have to do is take a backup of your primary and lay it onto your standby server without having to modify parameters in
your SPFILE (or init.ora file) that handles filename conversions.
Here are the steps for setting up an Oracle9i Database physical-standby database in managed-recovery mode. In this example, the
primary host name is primary_host, the standby host name is standby_host, and both the primary database and the standby database
are named BRDSTN. The mount points and directory structures are identical between the primary and standby servers.
1. Ensure that your primary database is in archive-log mode. The easiest way to check this is to log on to SQL*Plus as the SYS user
and issue the following command:
SQL> archive log list
The database-log mode must be "Archive Mode." If your primary database isn't in archive-log mode, enable this feature as follows:
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
2. Create a backup of your primary database. Back up only datafiles, not online redo log files or control files. You can view the files
you need to back up by querying V$DATAFILE:
SQL> select name from v$datafile;
You can use a hot, cold, or Recovery Manager (RMAN) backup to create the backup. I usually use a cold backup because there are
fewer steps involved.
3. Copy the backup datafiles to the standby server. Use your favorite network copy utility (FTP, SCP, etc.) to copy the backup files
generated from Step 2 to the standby server. If you use a hot (online) backup, you also need to transfer any archived redo logs
generated during the backup to the standby environment.
4. Create a standby control file. Create this via the ALTER DATBASE CREATE STANDBY command on the primary database.
This creates a special control file that will be used by a standby database.
log_archive_start = true
standby_archive_dest=
/ora01/oradata/BRDSTN
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /ora01/app/oracle/product/9.2.0)
(PROGRAM = extproc)
)
(SID_DESC =
(SID_NAME = BRDSTN)
(ORACLE_HOME = /ora01/app/oracle/product/9.2.0))
Primary tnsnames.ora file. I recommend placing both the primary and standby service locations in the tnsnames.ora file on both the
primary and standby servers. This makes troubleshooting easier and also makes failover and switchover operations smoother. In this
example, primary1 points to the primary database on a host named primary_host, and standby1 points to the standby database on
a server named standby_host.
The following text describes the connection for the primary tnsnames.ora file:
primary1 =
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (PORT=1521) (HOST=primary_host))
(CONNECT_DATA=(SERVICE_NAME=BRDSTN)))
standby1 =
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /ora01/app/oracle/product/9.2.0)
(PROGRAM = extproc)
)
(SID_DESC =
(SID_NAME = BRDSTN)
(ORACLE_HOME = /ora01/app/oracle/product/9.2.0))
Standby tnsnames.ora file. The following is the same connection information entered into the primary server tnsnames.ora file:
primary1 =
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (PORT=1521) (HOST=primary_host))
(CONNECT_DATA=(SERVICE_NAME=BRDSTN)))
standby1 =
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (PORT=1521) (HOST=standby_host))
(CONNECT_DATA=(SERVICE_NAME=BRDSTN)))
When you operate Oracle Data Guard in managed-recovery mode, it is critical to have Oracle Net connectivity between the primary and
standby databases.
9. Start up and mount the standby database. The standby database needs to be started and mounted in standby mode. On the
standby database, execute the following:
SQL> startup nomount;
SQL> alter database mount standby database;
10. Enable managed-recovery mode. To enable automatic copying and application of archived redo logs, place the standby database
in managed-recovery mode as follows:
SQL> recover managed standby database disconnect;
At this point, you should be able to generate archive redo information on your primary database and see it applied to the standby. As you
deploy your Oracle Data Guard environment and perform maintenance operations, pertinent messages are often written to the primary
and standby alert.log files. I've found that concepts jell more quickly and issues are resolved more rapidly when I simultaneously monitor
the contents of both the standby and primary alert.log files. In a UNIX environment, the tail command is particularly helpful in this regard:
$ tail -f alert_BRDSTN.log
Most of the problems you'll encounter with your Oracle Data Guard physical-standby database setup will be because either Oracle Net
was not configured correctly or you fat-fingered an initialization parameter. The alert logs are usually pretty good at pointing out the
source of the problem.
Data Guard SQL Apply
Prior to Oracle9i Database Release 2, you could implement only a physical-standby database. One aspect of a physical-standby
database is that it can be placed in either recovery mode or read-only mode, but not both at the same time.
With the new Data Guard SQL Apply feature of Oracle9i Database Release 2, you can now create a logical-standby database that is
continuously available for querying while simultaneously applying transactions from the primary. This is ideal if your business requires a
near-real-time copy of your production database that is also accessible 24/7 for reporting.
A logical-standby database differs architecturally from a physical-standby database, which is physically identical to the primary database
block-for-block, because the Oracle media-recovery mechanism is used on the redo information received from the primary database to
apply those redo changes to a physical data-block address.
Unlike a physical-standby database, a logical-standby database transforms the redo data received from the primary into SQL statements
(using LogMiner technology) and then applies the SQL statements. It is logically identical to the primary database but not physically
identical at the block level.
Just like a physical-standby database, a logical-standby database can assume the role of the primary database in the event of a
disaster. You can configure your Data Guard environment to use a combination of both logical-standby and physical-standby databases.
If you use your logical-standby database for reporting, you can further tune it by adding indexes and materialized views independent of
the primary.
There are many steps involved with setting up a logical-standby database. The best sources for detailed instructions are MetaLink note
186150.1 and the Oracle9i Database Release 2 Oracle Data Guard Concepts and Administration manual.
Archive-Gap Management
In a managed-recovery configuration, if the primary log-transport mechanism isn't able to ship the redo data from the primary database
to the physical-standby database, you have a gap between what archive logs have been generated by the primary database and what
have been applied to the physical-standby database. This situation can arise if there is a network problem or if the standby database is
unavailable for any reason.
Detecting and resolving archive gaps is crucial to maintaining high availability. An
untimely gap-resolution mechanism compromises the availability of data in the standby Next Steps
environment. For example, if you have an undetected gap and disaster strikes, the
result is a loss of data after you fail over to your standby database. READ Oracle Data Guard documentation
In Oracle8i, you had the responsibility of manually monitoring gaps. After you detected /docs/products/oracle9i
a gap, you then had to manually perform the following steps on your standby database: /deploy/availability/pdf/DG92_ TWP.pdf
metalink.oracle.com
• Determine which archived redo logs are part of the gap
• Manually copy those archived redo gap logs to standby
• Take the standby database out of managed-recovery mode
• Issue the RECOVER STANDBY DATABASE command
• Alter the standby database back into managed-recovery mode
With Oracle9i Database, Data Guard has two mechanisms for automatically resolving gaps. The first mechanism for gap resolution uses
a periodic background communication between the primary database and all of its standby databases. Data Guard compares log files
generated on the primary database with log files received on the standby databases to compute the gaps. Once a gap is detected, the
missing log files are shipped to the appropriate standby databases. This automatic method does not need any parameter configuration.
The second mechanism for automatic gap resolution uses two new Oracle9i Database initialization parameters on your standby
database:
SQL> alter system set FAL_CLIENT = standby1;
SQL> alter system set FAL_SERVER = primary1;
Once these parameters are set on the standby database, the managed-recovery process in the physical-standby database will
automatically check and resolve gaps at the time redo is applied.
Convert tablespace
8.1.6 now gives two built-in functions to allow you to switch back and forth between dictionary and
locally managed tablespaces without unloading/reloading the data. It was 8.1.5 that introduced the
dbms_space_admin package which is used 'behind the scenes' to probe the tablespace bitmaps in
locally managed tablespace, mainly for use in the everyday views DBA_EXTENTS and
DBA_SEGMENTS. In 8.1.6, two new procedures have been added to the package:
• DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_TO_LOCAL
• DBMS_SPACE_ADMIN.TABLESPACE_MIGRATE_FROM_LOCAL
• When converting from dictionary management to locally management, a "full conversion" does
not actually take place - simply an appropriate bitmap is built to map the existing extents, along
with some rounding of the space used. Thus you end up with an interesting hybrid, where if you
query DBA_TABLESPACES, you will see that management policy is LOCAL but the allocation
policy is USER (not uniform or automatic). In short, you will have definitely solved one problem,
that of stress on UET$ and FET$, but you are not guaranteed to resolve the fragmentation
issue. Even so, in a tightly managed production environment, steps to avoid fragmentation
should already be in place.
• When converting from dictionary management to locally management, there must be some free
space in the tablespace hold the bitmap that will be created (at least 64k), otherwise migration
will fail.
Finally, the documentation also provides a "tempter", that local management of the SYSTEM
tablespace will also be supported in future..
Update
When converting from a dictionary managed tablespace to a locally managed one, then produce a
bitmap that all extents can be mapped by, clearly each bit in the bitmap must represent a size that will
divide evenly into:
and Oracle also ensures that if you have set the MINIMUM EXTENT clause, then this is respected as
well. The documentation says that during conversion, it will try to find the largest suitable extent size,
that is, the greatest commmon denominator of all of the used/free extents.
However, it would appear that one very critical factor is not documented. If a MINIMUM EXTENT
clause has NOT been specified, then rather than this clause being ignored, Oracle assumes it to be
the smallest possible size of an extent (whether it exists or not). In an 8k block size database, this is
40k (Oracle rounds extents bar the initial one up to 5 blocks), so no matter what distribution of extents
you have, the bitmap will always be chosen as 1bit per 40k, unless you specify the MINIMUM
EXTENT clause.
Example:
Tablespace created.
Table created.
Table created.
Table created.
BYTES
------------
409,600
819,200
1,228,800
--
-- So at this stage, one would imagine that the unit size for a conversion
-- to a locally managed tablespace is 50 ( 50 * 8192 = 400k ). But if we try...
--
*
ERROR at line 1:
ORA-03241: Invalid unit size
ORA-06512: at "SYS.DBMS_SPACE_ADMIN", line 0
ORA-06512: at line 1
--
-- But if we set the minimum extent...
--
Tablespace altered.
SQL>
Log Buffer
Other Buffer Caches (KEEP/RECYCLE, other block sizes)
Streams Pool (new in Oracle Database 10g)
Fixed SGA and other internal allocations
A new background process named Memory Manager (MMAN) manages the automatic shared memory.
Data Pump
High performance import and export
• 60% faster than 9i export (single thread)
• 15x-45x faster than 9i import (single thread)
The reason it is so much faster is that Conventional Import uses only conventional mode inserts, whereas Data
Pump Import uses the Direct Path method of loading. As with Export, the job can be parallelized for even more
improvement dynamically. Creates a separate dump file for each degree of parallelism.
Import Command
===============
oracle@testserver-test2>impdp hh/xxxxx dumpfile=pump_dir:test_tbs_full_db.dmp schemas=devuser
remap_tablespace=system:users
Flashback Database
10g method for point-in-time recovery
1. Shutdown the database
2. Startup the database in mount state
3. SQL> flashback database to timestamp to_timestamp(‘2004-12-16 16:10:00’, ‘YYYY-
MM-DD HH24:MI:SS’);
4. Open the database – open resetlogs
New strategy for point-in-time recovery
Flashback Log captures old versions of changed blocks.
• Think of it as a continuous backup
• Replay log to restore DB to time
• Restores just changed blocks
It’s fast - recovers in minutes, not hours. More over, this feature removes the need for database incomplete
recoveries that require physical movement of datafiles/restores.
It’s easy - single command restore
• SQL> Flashback Database to scn 1329643
Rename Tablespace
10g method for renaming tablespaces
SQL> alter tablespace users rename to users3;
Oracle allows the renaming of tablespaces in 10g. A simple alter tablespace command is all you need.
• alter tablespace offline/online to flush the buffer cache of blocks relating to that tablespace (As
per Tom Kytes Article).
Flashback Drop
10g method for undoing a dropped table
SQL> flashback table emp to before drop;
• Recycle Bin (Sounds familiar)……….A logical representation of the dropped object. The
dropped/renamed table is still occupying space in it’s original tablespace. You can still query it
after it’s dropped.
• You can empty out the recycle bin by purging the objects.
Flashback Table
9i method for restoring data
INSERT INTO emp (SELECT * FROM emp AS OF TIMESTAMP TO_TIMESTAMP(’16-Sep-04
1:00:00’,’DD-MON-YY HH24:MI:SS’) MINUS SELECT * FROM emp );
10g method for restoring data
Flashback table emp to TIMESTAMP
TO_TIMESTAMP(’16-Sep-04 1:00:00’,’DD-MON-YY HH24:MI:SS’)
Make sure you enable row movement prior to the restore.
SQL> alter table emp enable row movement;
Flashback Transaction Query
8i/9i method for generating sql undo statements
Log Miner (Good luck parsing through those logs).
10g method for generating sql undo statements
SELECT undo_sql FROM flashback_transaction_query WHERE table_owner=‘SCOTT’
AND table_name=‘EMP’ AND start_scn between 21553 and 44933;
(You can also use timestamp)
Flashback Transaction Query provides the ability to generate the SQL statements for undoing DML .