Sunday, December 4, 2011

Gathering stats in the database

Version 9.2 onwards You can gather stats of the database by the below ways:

GATHER_TABLE_STATS
EXEC DBMS_STATS.GATHER_TABLE_STATS (ownname =>'SCHEMA_NAME'',tabname=>'TABLE_NAME',method_opt => 'FOR ALL INDEXED COLUMNS SIZE AUTO',granularity =>'ALL',cascade => TRUE,degree => DBMS_STATS.DEFAULT_DEGREE);

GATHER_INDEX_STATS
Execute DBMS_STATS.GATHER_INDEX_STATS ('TEST','TEST_PK',estimate_percent => 30, degree => 6);

GATHER_SCHEMA_STATS
EXEC DBMS_STATS.GATHER_TABLE_STATS (ownname =>'SCHEMA_NAME'',estimate_percent=>dbms_stats.auto_sample_size,cascade=>TRUE,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree => 12)

Renaming table in Oracle

In Oracle you can rename a table in the same schema as below:

alter table OWNER. rename to NEW_TABLE NAME;

Here the new table will be created in the OWNER schema. Here the target table's schema name need not be required to mention.

Monday, November 7, 2011

Oracle database Broken job 10g

TO check status of broken job:

SQL> select job, broken,what from dba_jobs
JOB BROKEN WHAT
----- ------ ----
3 N PROC1;
2 Y PROC2;

Here the BROKEN column of job 2 is Y which means that this is a broken one.

To mark it as not broken:

EXEC DBMS_JOB.BROKEN(2,FALSE);


TO verify if the broken job is fixed.

SQL> select job, broken,what from dba_jobs

JOB BROKEN WHAT
--- ---- ----
3 N PROC1;
2 N PROC2;

Sunday, October 30, 2011

Invalid XML/EXF/CATALOG/CATPROC component in registry

In one of my database, I found that my XML/EXF/CATALOG/CATPROC component in registry got invalid.


COMP_ID COMP_NAM STATUS
---------- ----------------------- ---------
EXF Oracle Expression Filter INVALID
CATALOG Oracle Database Catalog Views INVALID
CATPROC Oracle Database Packages and Types INVALID
JAVAVM JServer JAVA Virtual Machine VALID
XML Oracle XDK INVALID
CATJAVA Oracle Database Java Packages VALID

6 rows selected.


Steps below:

SHUTDOWN IMMEDIATE
STARTUP UPGRADE
@?/rdbms/admin/catalog.sql
@?/rdbms/admin/catproc.sql
@?/rdbms/admin/catexf.sql

-- To validate EXF components
@utlrp.sql

SHUTDOWN IMMEDIATE

STARTUP

Finally all components became valid:

SQL> select COMP_ID,COMP_NAME,STATUS from dba_registry;

COMP_ID COMP_NAM STATUS
---------- ----------------------- ---------
EXF Oracle Expression Filter VALID
CATALOG Oracle Database Catalog Views VALID
CATPROC Oracle Database Packages and Types VALID
JAVAVM JServer JAVA Virtual Machine VALID
XML Oracle XDK VALID
CATJAVA Oracle Database Java Packages VALID

6 rows selected.

SQL> select owner,count(*) from dba_objects where status='INVALID' group by owner;

OWNER COUNT(*)
------------------------------ ----------
PUBLIC 25
SYS 73
EXFSYS 20

Run utlrp

@?/rdbms/admin/utlrp.sql

SQL> select owner,count(*) from dba_objects where status='INVALID' group by owner;

OWNER COUNT(*)
------------------------------ ----------
PUBLIC 21
SYS 43
EXFSYS 2

SQL> SQL> select COMP_ID,COMP_NAME,STATUS from dba_registry;

COMP_ID COMP_NAM STATUS
---------- ----------------------- ---------
EXF Oracle Expression Filter VALID
CATALOG Oracle Database Catalog Views VALID
CATPROC Oracle Database Packages and Types VALID
JAVAVM JServer JAVA Virtual Machine VALID
XML Oracle XDK VALID
CATJAVA Oracle Database Java Packages VALID

6 rows selected.

Monday, October 3, 2011

WARNING: Inbound connection timed out (ORA-3136) after DR

I just want to share one of my experience today with this error.
We did a DR test on one of our informatica standby database server using flashback letting primary database up and used by the application. Basically here standby database was opened as standalone database after cancelling the media recovery and opening the database. Before opening we enabled flashback in the database.

There was n number of issues faced and i would like to write on it in a separate post. Lets discuss considering error Inbound connection timed out (ORA-3136)
After we got the standby database after the application test during DR to put it back in sync with primary database and we did so.
After syncing though i was seeing that both the primary and standby was in sync i was continuouly seeing below error in alert log if standby database:


WARNING: inbound connection timed out (ORA-3136)
Sun Oct 2 20:10:50 2011
WARNING: inbound connection timed out (ORA-3136)
Sun Oct 2 20:11:20 2011
WARNING: inbound connection timed out (ORA-3136)
Sun Oct 2 20:11:51 2011
WARNING: inbound connection timed out (ORA-3136)
Sun Oct 2 20:12:21 2011
WARNING: inbound connection timed out (ORA-3136)
Sun Oct 2 20:12:31 2011
WARNING: inbound connection timed out (ORA-3136)



When I checked it further in sqlnet.log, it tells that the connection to the standby database is coming continuously from Informatica production server


***********************************************************************
Fatal NI connect error 12170.

VERSION INFORMATION:
TNS for Solaris: Version 10.2.0.3.0 - Production
Oracle Bequeath NT Protocol Adapter for Solaris: Version 10.2.0.3.0 - Production
TCP/IP NT Protocol Adapter for Solaris: Version 10.2.0.3.0 - Production
Time: 02-OCT-2011 19:53:15
Tracing not turned on.
Tns error struct:
ns main err code: 12535
TNS-12535: TNS:operation timed out
ns secondary err code: 12606
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=148.168.**.**)(PORT=12345))


***********************************************************************
Fatal NI connect error 12170.

VERSION INFORMATION:
TNS for Solaris: Version 10.2.0.3.0 - Production
Oracle Bequeath NT Protocol Adapter for Solaris: Version 10.2.0.3.0 - Production
TCP/IP NT Protocol Adapter for Solaris: Version 10.2.0.3.0 - Production
Time: 02-OCT-2011 19:53:25
Tracing not turned on.
Tns error struct:
ns main err code: 12535
TNS-12535: TNS:operation timed out
ns secondary err code: 12606
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=148.168.**.**)(PORT=12345))
***********************************************************************


SQL> !nslookup 148.168.**.**)(
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
53.67.168.148.in-addr.arpa name = server001.pfizer.com.

Authoritative answers can be found from:


========================================================================


When i checked the server details of server001.pfizer.com in CMDB, i got to know that its informatica production application server. Then it understood that during DR application would have been pointed to the DR standby databaase and later after DR, they missed to disconnect those informatica connection to DR standby database.

Then i requested informatica team to disconnect and disable those connection to standby database from informatica production application server. Once this was done this error WARNING: Inbound connection timed out (ORA-3136) disappeared :).

Sunday, April 25, 2010

Automating Database Refreshes using BCV

Steps:
1. Backup’s of the tables/database.
2. BCV snapshot of the SOURCE database
3. BRING DOWN THE LISTENERS
4. TAKE A TRACE OF THE CONTROL FILE
5. REUSE THE TRACE CONTROL FILE to MAKE THE CONTROL FILE OF THE SOURCE DATABASE ON THE TEST SERVER
6. USE THE TRACE CONTROL FILE to MAKE THE CONTROL FILE OF THE TARGET DATABASE ON THE TEST SERVER
7. RUN all THE POST DATABASE SCRIPTS
8. BRING UP THE LISTENERS



BACKUP of the tables/Databases

Please ensure that before you start the refresh process you take a backup of the tables which are needed to be backed up.


BCV snapshot of the database

You can do this step in coordination with unix team where in you can request unix team/System Administrator to take a BCV snap shot of the database server from which you needs your development/test database to be refreshed. For this methodology storage team use to set up some SRDF disks on the server on which the BCV needs to be set up. Here I am taking an assumption that production database name is SOURCE-DB and the database needs to be refreshed is TARGET-DB

Once BCV is completed by the SA’s these BCV disks are placed on the dev/test server. Once this is completed, The BCV disks will be looking as below:


/dev/vx/dsk/bldmx1dg/d1000n
10G 7.6G 2.3G 78% /d1000b
/dev/vx/dsk/bldmx1dg/d1001n
172G 156G 15G 92% /d1001b
/dev/vx/dsk/bldmx1dg/d1002n
182G 119G 59G 68% /d1002b
/dev/vx/dsk/bldmx1dg/d1003n
182G 122G 57G 69% /d1003b
/dev/vx/dsk/bldmx1dg/d1004n
182G 118G 60G 67% /d1004b
/dev/vx/dsk/bldmx1dg/d1005
182G 112G 66G 63% /d1005b
/dev/vx/dsk/bldmx1dg/d1006
182G 182G 92M 100% /d1006b
/dev/vx/dsk/bldmx1dg/d1007
182G 155G 25G 87% /d1007b
/dev/vx/dsk/bldmx1dg/d1008
182G 128G 51G 72% /d1008b
/dev/vx/dsk/bldmx1dg/d1009
182G 137G 42G 77% /d1009b
/dev/vx/dsk/bldmx1dg/d1010
182G 82G 94G 47% /d1010b
/dev/vx/dsk/bldmx1dg/d1011
182G 97G 80G 55% /d1011b
/dev/vx/dsk/bldmx1dg/d1012
182G 61G 114G 35% /d1012b
/dev/vx/dsk/bldmx1dg/d1013
182G 64G 111G 37% /d1013b
/dev/vx/dsk/bldmx1dg/d1014
182G 110G 67G 63% /d1014b
/dev/vx/dsk/bldmx1dg/d1015
182G 98G 79G 56% /d1015b
/dev/vx/dsk/bldmx1dg/d1016
364G 363G 945M 100% /d1016b
/dev/vx/dsk/bldmx1dg/d1017
364G 360G 3.5G 100% /d1017b



Above ‘b’ in /d****b represents the BCV disks.



BRING DOWN THE LISTENERS


echo "Stopping listener : `date`" >> ${BCV_LOG}

lsnrctl stop

TAKE A TRACE OF THE CONTROL FILE


Here we use to bring up the database as SOURCE-DB on the test server. This is done because while the database BCV was done there were already many transactions are running on the database. So you need to shut down the database cleanly.

Below is the script that we use to bring up SOURCE database on the test server and then shut it down cleanly to have its SMON do all the transaction recovery.

Step1: set up the oracle environments. Here in my case I am using script /var/opt/oracle/env/.env to set up the environment

/var/opt/oracle/env/.env

Set the ORACLE_SID correctly.

export ORACLE_SID=

Connect as sysdba to the database and redirecting this to a log file $BCV_LOG
sqlplus "/ as sysdba" <>${BCV_LOG}

Startup the database with the spfile/pfile of the source database. Here you can use of minimal parameters which are required to bring up the database
startup mount pfile=/var/opt/oracle/product/9.2.0.5.0/dbs/init.ora;



The above command will bring up the database SOURCE-DB on the target server using the control files of SOURCE-DB on the target server that is a copy of the CONTROL file of the SOURCE DATABASE of the source server.

Now take a trace of the control file. We are doing this so as to REUSE and recreate the control file of the SOURCE DATABASE on the test box.


alter database backup controlfile to trace as '/d1000/var/opt/oracle/admin//udump/control__$proc_date.trc'; --------------------------------------1

Now shut down this database
shutdown immediate
exit
eot

REUSE THE TRACE CONTROL FILE to MAKE THE CONTROL FILE OF THE SOURCE DATABASE ON THE TEST SERVER

Below we are going to the location where the command 1 will create the trace file.

echo "Creating control file script for : `date`" >> ${BCV_LOG}
cd /d1000/var/opt/oracle/admin//udump

Now below is what we are doing:
i. Below is the sample trace file which we get on execting step1



ii. On this trace file we are running the below script which will give us a modified script where in below will be the changes
TARGET-DB to SOURCE-DB
RESETLOG to NORESETLOGS
ARCHIVELOG to NOARCHIVELOG

Also because the mount point name (in my case its /d***b)) on the target server is different as compared to that of the SOURCE SERVER(here name is /d****). If this is not the case in your case you can skip the below changes
d1001/d1001b
d1002/d1002b
d1003/d1003b
d1004/d1004b
d1005/d1005b
d1006/d1006b
d1007/d1007b
d1008/d1008b
d1009/d1009b
d1010/d1010b
d1011/d1011b
d1012/d1012b
d1013/d1013b
d1014/d1014b
d1015/d1015b
d1016/d1016b
d1017/d1017b
iii. Here basically there are two control file script in the trace file so we are taking one and passing all these to file control_.sql.
iv. Below is the script that we are using.

sed -e "1,/# be invalidated/d" -e "s///g" -e "s/RESETLOGS/NORESETLOGS/g" -e "s/ARCHIVELOG/NOARCHIVELOG/g" -e "/d200/d" -e "s/d1001/d1001b/g" -e "s/d1002/d1002b/g" -e "s/d1003/d1003b/g" -e "s/d1004/d1004b/g" -e "s/d1005/d1005b/g" -e "s/d1006/d1006b/g" -e "s/d1007/d1007b/g" -e "s/d1008/d1008b/g" -e "s/d1009/d1009b/g" -e "s/d1010/d1010b/g" -e "s/d1011/d1011b/g" -e "s/d1012/d1012b/g" -e "s/d1013/d1013b/g" -e "s/d1014/d1014b/g" -e "s/d1015/d1015b/g" -e "s/d1016/d1016b/g" -e "s/d1017/d1017b/g" -e "/^# Configure snapshot controlfile filename/,/^$/d" -e "s/STARTUP NOMOUNT//g" -e "/^$/d" -e "s/ALTER/---ALTER/g" control__$proc_date.trc > control_.sql


v. Run the generated control file for the database.

. /var/opt/oracle/env/.env
export ORACLE_SID=
sqlplus "/ as sysdba" <>${BCV_LOG}

startup nomount pfile=/var/opt/oracle/product/9.2.0.5.0/dbs/init.ora;
@control_.sql

This will create the control file for the SOURCE-DB. Above we are bringing up the instance as nomount using the pfile of the SOURCE-DB.

vi. Recovery
As ofcourse the database will ask for recovery and we will recover as below and once the media recovery completes we will be open the database.

recover database;
alter database open;


vii. Do a clean shut down of this database
DO a clean shut down of this database as this will disable the TX recovery process as well.

shutdown immediate;
eot









USE THE TRACE CONTROL FILE to MAKE THE CONTROL FILE OF THE TARGET DATABASE ON THE TEST SERVER



viii. On this trace file we are running the below script which will give us a modified script where in below will be the changes
REUSE to SET
SOURCE-DB to TARGET-DB
NORESETLOG to RESETLOGS
NOARCHIVELOG to ARCHIVELOG

Also because the mount point name (in my case its /d***b)) on the target server is different as compared to that of the SOURCE SERVER(here name is /d****). If this is not the case in your case you can skip the below changes
d1001/d1001b
d1002/d1002b
d1003/d1003b
d1004/d1004b
d1005/d1005b
d1006/d1006b
d1007/d1007b
d1008/d1008b
d1009/d1009b
d1010/d1010b
d1011/d1011b
d1012/d1012b
d1013/d1013b
d1014/d1014b
d1015/d1015b
d1016/d1016b
d1017/d1017b
ix. Here basically there are two control file script in the trace file so we are taking one (here with the SET option) and passing all these to file control_.sql

x. Below is the script that we are using.


echo "Creating control file script for : `date`" >> ${BCV_LOG}
cd /d1000/var/opt/oracle/admin//udump


sed -e "1,/# be invalidated/d" -e "s/REUSE/SET/g" -e "s///g" -e "s/NORESETLOGS/RESETLOGS/g" -e "s/ARCHIVELOG/NOARCHIVELOG/g" -e "/d200/d" -e "s/d1001/d1001b/g" -e "s/d1002/d1002b/g" -e "s/d1003/d1003b/g" -e "s/d1004/d1004b/g" -e "s/d1005/d1005b/g" -e "s/d1006/d1006b/g" -e "s/d1007/d1007b/g" -e "s/d1008/d1008b/g" -e "s/d1009/d1009b/g" -e "s/d1010/d1010b/g" -e "s/d1011/d1011b/g" -e "s/d1012/d1012b/g" -e "s/d1013/d1013b/g" -e "s/d1014/d1014b/g" -e "s/d1015/d1015b/g" -e "s/d1016/d1016b/g" -e "s/d1017/d1017b/g" -e "/^# Configure snapshot controlfile filename/,/^$/d" -e "s/STARTUP NOMOUNT//g" -e "/^$/d" "s/ALTER/---ALTER/g" control__$proc_date.trc > control_.sql

xi. Run the generated control file for the database.
xii. Here before you run the control file script @control_.sql, you need to make sure that you are removing/moving the control files which are older one and are on the same location as per the pfile/spfile that is being used to bring up SOURCE-DB database.


mv /d1001b/oradata//control01.ctl /d1001b/oradata//control01.ctl.bkp
mv /d1002b/oradata//control02.ctl /d1002b/oradata//control02.ctl.bkp

. /var/opt/oracle/env/.env
export ORACLE_SID=
sqlplus "/ as sysdba" <>${BCV_LOG}

startup nomount
@control_.sql

This will create the control file for the SOURCE-DB. Above we are bringing up the instance as nomount using the pfile of the SOURCE-DB.

xiii. Reset all the logs
Here as we don’t need the redo logs of the SOURCE-DB reset all the logs

alter database open resetlogs;

xiv. shut down of this database
DO a clean shut down of this database as this will disable the TX recovery process as well.

shutdown immediate;
eot

xv. Create the password file
Before creating remove the older password file

cd $ORACLE_HOME/dbs
rm orapw
orapwd file=orapw password=spongeb entries=5

xvi. Start the database

export ORACLE_SID=
sqlplus "/ as sysdba" <>${BCV_LOG}



RUN all THE POST DATABASE SCRIPTS

You may need to run the past database refresh scripts like below and if anything else you may include in your script as well.

!sleep 10
set echo on
spool post_refresh__$proc_date.lst
@/var/opt/oracle/scripts/POST_change_passwords.sql
@/var/opt/oracle/scripts/post__sql.sql
@/var/opt/oracle/scripts//post__others.sql


spool off
exit

eof

BRING UP THE LISTENERS

echo "Starting listener : `date`" >> ${BCV_LOG}

lsnrctl start