Oracle : Oracle® Database High Availability Best Practices 10g Release 2 (10.2) Part Number B25159-01

Oracle® Database High Availability Best Practices
10g Release 2 (10.2)
Part Number B25159-01

http://download.oracle.com/docs/cd/B19306_01/server.102/b25159/toc.htm

Oracle : Unregister database from RMAN Catalog

Login as rman catalog owner.

SQLPLUS> select * from rc_database where dbid = DBID;

SQLPLUS> exec dbms_rcvcat.unregisterdatabase(DBKEY, DBID);

Oracle : Reference List of Critical Patch Update Availability Documents For Oracle Database and Fusion Middleware Product [ID 783141.1]

A good reference for the List of CPU for Oracle database. Metalink account is needed.

Reference List of Critical Patch Update Availability Documents For Oracle Database and Fusion Middleware Product [ID 783141.1]

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=HOWTO&id=783141.1

Oracle : Create database link on another schema

Even as an administrator for the database, it sometime possible that we don't have the password of the schema. Most of the time we can just log in as SYS and then create the objects for the particular schema.

For example we can create a table for a particular schema by just added the owner name before the table name.

Create table AAA.TEST (A CHAR);

The table will be create under the ownership of the schema AAA.

However this is not possible for database link. As the syntax for creating database link does not take owner into consideration.

If you would create a database link using

Create database link AAA.TESTLNK ....

You will end up with a database link "AAA.TESTLINK" owner by SYS.

So the trick now is to create a procedure under the schema that create the database link. This way the database link will be create under the ownership of the schema and not SYS. Script as below :


create or replace procedure AAA.CREATEDBLINK
is
begin
execute immediate 'create database link TESTLINK
connect to BBB identified by "Password"
using ''REMOTEINSTANCE''';
end;
/

Execute the procedure AAA.CREATEDBLINK to create the database link

exec AAA.CREATEDBLINK

Subsequently drop the procdure.

drop procedure AAA.CREATEDBLINK;


Original source : http://forums.oracle.com/forums/thread.jspa?threadID=507523

Oracle : List Table Names, Rows, and Created Date

During migration it is best to do a row count between the old and new database.
Below is a script that I have adapted from another author to do a role count for all the tables belonging to the schemas (object owners). We will run the script on the old and new database. Spool out the file and subsequently we can just do a diff ( unix command ) on the 2 files to see if there is a difference. If there are no difference we can safely assume the number of rows migrated from the old database to the new database are correct.

* replace ('AAA','BBB','CCC') with the schemas names.

set linesize 999
set trimspool on
set pagesize 999
set serveroutput on size 100000 feedback off

declare
rs integer;
cur integer;
rp integer;
trs integer;
n integer;
un varchar2(30);
begin
dbms_output.put_line(rpad('Owner',15)||rpad('Table Name',40)||' Number of Rows');
dbms_output.put_line(rpad('-',73,'-'));
cur:= dbms_sql.open_cursor;
for t in (select owner, table_name from dba_tables where owner in ('AAA','BBB','CCC') order by owner, table_name) loop
dbms_sql.parse(cur,'select count(*) from ' || t.owner || '.' || t.table_name, dbms_sql.v7);
dbms_sql.define_column(cur, 1, rs);
rp:= dbms_sql.execute(cur);
n:=dbms_sql.fetch_rows(cur);
dbms_sql.column_value(cur, 1, rs);
dbms_output.put_line(rpad(t.owner,23)||rpad(t.table_name,48,'.')||rpad(rs,15,'.'));
end loop;
dbms_sql.close_cursor(cur);

end;
/

set serveroutput off feedback on feedback 6


Orignal article : http://www.oracle.com/technology/oramag/code/tips2004/011104.html

Original Script :

This tip comes from Pasupuleti Sailaja, in Hyderabad, Andhra Pradesh, India.


Description: -- Aim : To display table names, number of rows existed in table
-- and table created date in current login user for any ORACLE version
-- Usage : Step 1) All lines from given program save with filename DIR.SQL
-- Step 2) Run the file DIR.SQL by giving START DIR (or) @ DIR at SQL *Plus prompt
-- i.e. SQL> @ DIR
-- Author : Pasupuleti Sailaja, ORACLE favorite, Hyderabad-500072, India.
-- E-mail : SAILAJAMAIL@YAHOO.COM
-- Program :

set serveroutput on size 100000 feedback off

declare
rs integer;
cur integer;
rp integer;
trs integer;
n integer;
un varchar2(30);
begin
dbms_output.put_line(rpad('Table Name',40)||' Number of Rows Created Date');
dbms_output.put_line(rpad('-',73,'-'));
cur:= dbms_sql.open_cursor;
for t in (select object_name, created from user_objects where object_type='TABLE') loop
dbms_sql.parse(cur,'select count(*) from ' || t.object_name, dbms_sql.v7);
dbms_sql.define_column(cur, 1, rs);
rp:= dbms_sql.execute(cur);
n:=dbms_sql.fetch_rows(cur);
dbms_sql.column_value(cur, 1, rs);
dbms_output.put_line(rpad(t.object_name,48,'.')||rpad(rs,15,'.')||t.created);
end loop;
dbms_sql.close_cursor(cur);
select count(*) into n from tab where tabtype='TABLE';
select user into un from dual;
dbms_output.put_line(rpad('-',73,'-'));
dbms_output.put_line(un||' User contain '||n||' Table(s)');
end;
/
set serveroutput off feedback on feedback 6

Oracle : Handling Database Courrption.

When encountered database corruption. There are basically a couple of things that we can do. We will not describe the details here but here are some links to some of the documentation ( for 10gR2 )

1. DBVERIFY: Offline Database Verification Utility

This is a utility provided by Oracle to verify the status of your datafiles but does not repair the corrupted block. What it does is basically scanning through the datafile and marking the corrupted blocks.

If you suspect that a datafile is corrupted. Do a cold backup before you run this utility.

See more :
http://download.oracle.com/docs/cd/B19306_01/server.102/b14215/dbverify.htm#sthref1830


2. Using DBMS_REPAIR to Repair Data Block Corruption

A DBMS_REPAIR PL/SQL package provide by Oracle to repair data block corruption in database schema objects. However it is not necessary that it is able to recover all the data. Sometimes DBMS_REPAIR just makes the object usable by ignoring corruptions during table and index scans.

Taking note that DBMS_REPAIR does not work with LOBs.

See more :
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/repair.htm#i1006505


3. If you have a proper RMAN backup, you might be able to recover the corrupted block using RMAN. I have not tried this but below is a documentation with some details on how it can be done :
http://www.scribd.com/doc/2674976/Oracle-Database-Corruption

Oracle : ORA-01578: ORACLE data block corrupted, ORA-26040: Data block was loaded using the NOLOGGING option

When a object is set to nologging, it formats complete blocks of data itself, and writes them directly to the data file. Each time a commit is issued, the object's high water mark is raised so the new blocks are included in the object. These blocks do not go through the buffer cache in the Shared Global Area (SGA). The redo logs do not contain enough data to make the corresponding changes on a standby database, or roll forward in a recovery event. They only contain enough information to maintain the data dictionary and mark the new blocks as "invalidated" due to a nologging action.

Instance recovery uses the online redo logs to reconstruct the SGA after a crash, and to roll forward through the committed changes reflected there to make sure the data blocks are good. Since nologging operations write directly to the data files - bypassing the SGA - and each commit raises the high water mark to include the new blocks, instance recovery does not result in invalidated blocks on your production database. If a nologging operation is executing and the database suffers a crash, no new problems will be introduced to the environment due to nologging.

However, Oracle's database media recovery and Data Guard standby database technologies rely on the archived redo logs generated from database operations to replicate all changes to the data files. When you recover from a backup or activate a standby, you must roll forward through the redo logs to recreate these changes, to bring the restored or standby database to the desired point in time. Since nologging operations write directly to the data files and bypass the redo logs, rolling forward through redo for a nologging operation will result in invalidated blocks on your restored or standby database.

After you open your database, you will see the following errors if you rolled forward through a nologging operation while recovering from a backup or opening a standby:
ORA-1578: ORACLE data block corrupted (file # %s, block # %s)
ORA-26040: Data block was loaded using the NOLOGGING option

To make the standby or backup completely usable after a nologging statement is run, a mechanism other than database recovery must be used to get or create current copies of the affected blocks. There are two options, each of which may be appropriate depending on the specific circumstances:

* Create a new copy of the data files, either by backing up the tablespace again or by refreshing the specific data files on the standby.
* Drop and recreate the object with the invalidated blocks, using the program that maintains the object.

Release 9.2 of the database includes the ability to force logging across the database, or for particular tablespaces. With this or a later version, you can use the “force logging” feature to make sure all data changes are written to your database redo logs in a way that can be replayed on your restored backup, or propagated to a physical standby. You should test patches and affected production jobs with this feature invoked to be sure the performance impact is acceptable, before putting it into production. If you do this, you no longer need to do the work described in this document.

Nologging in the E-Business Suite [ID 216211.1]


Although oracle provides DBMS_REPAIR PL/SQL package to repair data block corruption in database schema objects, it is not necessary that it is able to recover all the data. Sometimes DBMS_REPAIR makes the object usable by ignoring corruptions during table and index scans. Taking note that DBMS_REPAIR does not work with LOBs.

It is therefore possible that there are no way to recover the data in an event of corruption as a result of the above described. So as a good practice to look out for nologging objects if the database is replicating using Dataguard.