Cluster Database Patching

Scope of this documentThis document is meant to provide all details for

Environment

ServerDatabaseHome Node
Failover Node
Prerequisite-

1> Check the Current version of the patches installed on the database2> Since oracle instances are owned by their respective OS user like (cvhdb75 or ),
Download the latest available patch only using the user who owns the instance to
avoid any permission issue.
3> Download the patches only in the filesystems belonging to oracle instance.
4> Once you cross check user and filesystem, download the latest available patch that
needs to be applied.
5> Ensure to download latest opatch along with the database patch.
6> Before proceeding next, make sure to check any patch conflict using the below
command7> Check space availability in the oracle home. Minimum 2 GB space is mandatory. If
filesystem lacks space you can raise a request to unix team. Example workorder isSteps For Unix TeamThis environment is HA cluster so we can not bring down the database because it is
configured to come up on the failpver node automatically. During patching we need to
disable this database failover with the help of Unix team.

Limitations1> Flashback Table operations are not valid for the following object types:
- Tables that are part of a cluster,- Materialized views ,- Advanced Queuing tables ,
Static data dictionary tables ,-System tables ,Partitions of a table ,Remote tables (via
database link)
2> if the following DDL commands are issued, the flashback table command does not
work
- ALTER TABLE ... DROP COLUMN
- ALTER TABLE ... DROP PARTITION
- CREATE CLUSTER
- TRUNCATE TABLE

Schneider Electrical

Page 1

Cluster Database Patching

- ALTER TABLE ... MOVE - ALTER TABLE ... ADD PARTITION - ALTER TABLE ... SPLIT
PARTITION - ALTER TABLE ... DISABLE / ENABLE PRIMARY KEY

Setup steps1> Set Undo Management to Auto.

2> Set the UNDO_RETENTION parameter to 86400 seconds (24 hours) or
greater for the undo tablespace.
ALTER SYSTEM SET UNDO_RETENTION = 86400;
3> Enable Undo Retention Guarantee.
SQL>alter tablespace UNDOTBS1 retention guarantee;
SQL>select tablespace_name,retention from dba_tablespaces;
TABLESPACE_NAME
RETENTION
------------------------------ ----------SYSTEM
NOT APPLY
UNDOTBS1
GUARANTEE

4> Enable row movement for the table which you want to flash back.
SQL> ALTER TABLE flash_test_table enable row movement;
Table altered.

Summary- Now all the changes performed on table which gets recorded in the undo
tablespaces will be retained guarantee till the undo retention period. This data can be
used to revert the table to previous timestamp before the error has occurred.

Schneider Electrical

Page 2

Cluster Database Patching

Steps to Recover data1> Figure out the Timestamp or the SCN number to which you want the table to
be reverted using the following queriescol current_scn form 999999999999999999
col TIMESTAMP_TO_SCN form 9999999999999999
col NOW10G form 99999999999999999999
col NOW9I form 99999999999999999999
col SCN form 99999999999999999999
col TIMESTAMP form 99999999999999999999
alter session set NLS_DATE_FORMAT='DD-MON-YY HH:MI:SS';
SQL>select current_scn from v$database;
CURRENT_SCN
------------------10900098356623

a) To convert an SCN to a TIMESTAMP the SCN_TO_TIMESTAMP (10g onwards)

is used
SQL>select SCN_TO_TIMESTAMP(10900098356623) from dual;
SCN_TO_TIMESTAMP(10900098356623)
--------------------------------------------------------------------------27-JUN-14 07.31.31.000000000 AM

b) To get a SCN from a timestamp

SQL>SELECT TIMESTAMP_TO_SCN(order_date) FROM orders WHERE order_id = 5000;
TIMESTAMP_TO_SCN(ORDER_DATE)
---------------------------574107

c) You can also use the ORA_ROWSCN pseudocolumn to determine the system
change number of the last update to a row and use SCN_TO_TIMESTAMP to
convert that SCN to a timestamp
SELECT SCN_TO_TIMESTAMP(ORA_ROWSCN) FROM employees
SCN_TO_TIMESTAMP(ORA_ROWSCN)
--------------------------------------------------------------------------28-AUG-03 01.58.01.000000000 PM

WHERE employee_id = 188;

2> Determine whether the table that you intend to flash back has dependencies
on other tables. If dependencies exist, then decide whether to flash back
these tables as well.
SELECT other.owner, other.table_name
FROM sys.all_constraints this, sys.all_constraints other
WHERE this.owner = schema_name
AND this.table_name = table_name
AND this.r_owner = other.owner
AND this.r_constraint_name = other.constraint_name
AND this.constraint_type='R';

Schneider Electrical

Page 3

Cluster Database Patching

3> FlashBack the table to previous state using the folloing command based on
timestamp or SCN.
SQL> flashback table flash_test_table to scn 332348;
OR
SQL> flashback table xxx to timestamp to_timestamp('2012-09-01 11:00:00', 'YYYY-MM-DD
HH24:MI:SS'
OR
SQL>FLASHBACK TABLE hr.temp_employees TO RESTORE POINT temp_employees_update;

4> Verify the data in the table to ensure data has been recovered.

Schneider Electrical

Page 4