Monday, June 9, 2008

ORA-00344 : unable to recreate


ORA-00344 unable to re-create


Example


RMAN> alter database open resetlogs;

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of alter db command at 06/09/2008 10:03:56

ORA-00344: unable to re-create online log 'D:ADMINDATAFILESREDOREDO03.LOG'

ORA-27040: skgfrcre: create error, unable to create file

OSD-04002: unable to open file

O/S-Error: (OS 3) The system cannot find the path specified.


In the example above we try to perform an "alter database open resetlogs" however we get an IO

error due the fact that the directory path "D:ADMINDATAFILESREDO" does not exist.


An additional side note is that in this example only the directory structure needs to be recreated ,

you do not need to have an actual redo log on file system , an "open resetlogs" will create a new

redo log as specified in the control file.


Details


ORA-00344: unable to re-create

ORA-27040: skgfrcre: create error, unable to create file

OSD-04002: unable to open file

O/S-Error: (OS 3) The system cannot find the path specified.


ORA-00344 is an IO error , you may have tried to open a database with incorrect redo log locations

specified in the control file.


Solution


You can either recreate the directory structure as specified in the error.


Create a new control file with the desired directory structure for the redo logs.


Tuesday, June 3, 2008

VERIFY CATCPU.SQL WAS EXECUTED

VERIFY IF CATCPU.SQL WAS EXECUTED
Strangley enough people often apply Oracle CPU's (Critical Patch Updates) without running catcpu.sql 
onces the binaries have been upgraded.

Check the readme for the CPU (Critical Patch Update ) for instruction on how catcpu.sql is executed.
The readme is accompanied with the patch from metalink.
When you apply CPU (Critical Patch Update ) on a Oracle home you are patching the binaries only.
Catcpu.sql is run to patch the database.


You
have to run catcpu.sql in an upgraded or newly created database from an oracle home where the
CPU patch is applied.


In an upgrade operation run catcpu.sql after running catpatch.sql (for 9i) or catupgrd.sql (for 10G).

For newly created database run catcpu.sql after starting up the database. This is to ensure that the
database vulnerabilities are fixed by making the necessary changes in the dictionary.

To Verify If catcpu.sql has been run against a database run the following:

col action_time for a28

col action for a6

col namespace for a9

col version for a10

col id for 99999999

col comments for a10

select * from registry$history;

e.g.

SQL> col action_time for a28

SQL> col action for a6

SQL> col namespace for a9

SQL> col version for a10

SQL> col id for 99999999

SQL> col comments for a10

SQL> select * from registry$history;

25-APR-08 10.17.22.950000 PM CPU SERVER 10.2.0.3.0 6637239 CPUJAN2008

25-APR-08 10.24.44.233000 PM CPU 6452863 view recom

pilation






Wednesday, May 28, 2008

ORA-38856: Cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled

ORA-38856: Cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled

Example:

In the example below the error Occurred while performing an open resetlogs on a 10.2.0.3 Oracle Single Instance Database
Server prior to restoring an RMAN backup of and Oracle Database. The RMAN backup was taken from a RAC Database Server
and restored to a Single Instance Box.

SQL> alter database open resetlogs;

alter database open resetlogs
*
ERROR at line 1:
ORA-38856: cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled


Details:

ORA-38856: cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled.


Oracle bug, 4355382 ORA-38856: FAILED TO OPEN DATABASE WITH RESETLOGS WHEN USING RAC BACKUP, exists in the
Oracle 10g release 2.0 that affects backups taken from a RAC database. The problem is related to the number of threads
used by the source database and an expectation that the cloned database must have an identical number of threads.


Solution:

1. Set the following parameter in the auxiliary init.ora file: _ no_recovery_through_resetlogs=TRUE.

2. Open the database in resetlogs mode.

3. Remove _ no_recovery_through_resetlogs=TRUE from init.ora.

4. Restart database.



Tuesday, May 20, 2008

ORA-39014

ORA-39014: One or more workers have prematurely exited.

Example:

In the example below the Error Occurred while using data pump expdp to perform a full export on a database.

ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW01" prematurely terminated
ORA-31672: Message 31672 not found; No message file for product=RDBMS, facility=ORA; arguments: [DW01]
Job "SYSTEM"."SYS_EXPORT_FULL_05" stopped due to fatal error at 22:15:39
ORA-39014: One or more workers have prematurely exited.


Details:


This is an Oracle Bug 5879865 Oracle Release 10.2.0.4. Patch 5879865. Fixed in the 11g release.

The problem is due to the query that uses an EXISTS sub-query involving a non-mergeable view causes the core dump.

ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW01" prematurely terminated
ORA-31672: Message 31672 not found; No message file for product=RDBMS, facility=ORA; arguments: [DW01]
Job "SYSTEM"."SYS_EXPORT_FULL_05" stopped due to fatal error at 22:15:39
ORA-39014: One or more workers have prematurely exited.


Solution:

1. If available for your Platform Download Patch 5879865 to resolve this issue.

2. In the meantime, please use one of the following as a workaround:

* set both of the following in the init/spfile

o "_complex_view_merging" = false
o event="38066 trace name context forever, level 1" or level 2

OR

* set "_optimizer_cost_based_transformation"=off

ORA- Error Codes

OORA- Error Codes
ORA-39014 ORA-38856 ORA-00344
ORA-12520
ORA-06512
ORA-29707
ORA-01618
ORA-12514 ORA-31633
ORA-01031
ORA-38760

Tuesday, May 13, 2008

Periodic Job to Purge Perfstat Stats Pack Metrics

Periodic Job to Purge Perfstat Stats Pack Metrics


You can use the following procedure to setup a database job to periodically purge the statspack metrics within

the perfstat schema ever "x" number of days , this can be used as an alternative to sppurge to manage space within

the perfstat schema


As the Perfstat User run create the following procedure

CREATE OR REPLACE PROCEDURE PERFSTAT.USP_SNAPSPURGE (vDAYS NUMBER)

AS

vMIN_SNAP_ID NUMBER;

vMAX_SNAP_ID NUMBER;

vDBID NUMBER;

vDBNAME VARCHAR2(50);

vINST_NUM NUMBER;

vINST_NAME VARCHAR2(50);

vSTIME DATE;

vBTIME VARCHAR2(25);

vETIME VARCHAR2(25);

SQL_STMT VARCHAR2(200);

ERROR_NUM NUMBER;

ERROR_MSG VARCHAR2(500);

BEGIN

select min(snap_id),max(snap_id) into vMIN_SNAP_ID,vMAX_SNAP_ID

from STATS$SNAPSHOT

where snap_time <=(sysdate-vDAYS);

select dbid,name into vDBID,vDBNAME

from v$database;

select instance_number,instance_name into vINST_NUM,vINST_NAME

from v$instance;

select to_char(snap_time, 'YYYYMMDD HH24:MI:SS') into vBTIME

from stats$snapshot b

where b.snap_id = vMIN_SNAP_ID

and b.dbid = vDBID

and b.instance_number = vINST_NUM;

select to_char(snap_time, 'YYYYMMDD HH24:MI:SS') into vETIME

from stats$snapshot e

where e.snap_id = vMAX_SNAP_ID

and e.dbid = vDBID

and e.instance_number = vINST_NUM;

-- **** check variables **** ---

delete from stats$snapshot

where instance_number = vINST_NUM

and dbid = vDBID

and snap_id between vMIN_SNAP_ID and vMAX_SNAP_ID;

SQL_STMT:='alter session set hash_area_size=1048576';

execute immediate (SQL_STMT);

delete --+ index_ffs(st)

from stats$sqltext st

where (hash_value, text_subset) not in

(select --+ hash_aj full(ss) no_expand

hash_value, text_subset

from stats$sql_summary ss

where ( ( snap_id < vMIN_SNAP_ID

or snap_id > vMAX_SNAP_ID

)

and dbid = vDBID

and instance_number = vINST_NUM

)

or ( dbid != vDBID

or instance_number != vINST_NUM)

);

delete --+ index_ffs(sso)

from stats$seg_stat_obj sso

where (dbid, dataobj#, obj#) not in

(select --+ hash_aj full(ss) no_expand

dbid, dataobj#, obj#

from stats$seg_stat ss

where ( ( snap_id < vMIN_SNAP_ID

or snap_id > vMAX_SNAP_ID

)

and dbid = vDBID

and instance_number = vINST_NUM

)

or ( dbid != vDBID

or instance_number != vINST_NUM)

);

delete from stats$undostat us

where dbid = vDBID

and instance_number = vINST_NUM

and begin_time >= to_date(vBTIME, 'YYYYMMDD HH24:MI:SS')

and end_time <= to_date(vETIME, 'YYYYMMDD HH24:MI:SS');

-- delete from stats$undostat us

-- where dbid = vDBID

-- and instance_number = vINST_NUM

-- and begin_time < to_date(vBTIME, 'YYYYMMDD HH24:MI:SS')

-- and end_time > to_date(vETIME, 'YYYYMMDD HH24:MI:SS');

/* Delete any dangling database instance rows for that startup time */

delete from stats$database_instance di

where instance_number = vINST_NUM

and dbid = vDBID

and not exists (select 1

from stats$snapshot s

where s.dbid = di.dbid

and s.instance_number = di.instance_number

and s.startup_time = di.startup_time);

/* Delete any dangling statspack parameter rows for the database instance */

delete from stats$statspack_parameter sp

where instance_number = vINST_NUM

and dbid = vDBID

and not exists (select 1

from stats$snapshot s

where s.dbid = sp.dbid

and s.instance_number = sp.instance_number);

COMMIT;

EXCEPTION

WHEN OTHERS THEN

ROLLBACK;

ERROR_NUM := SQLCODE;

ERROR_MSG := substr(SQLERRM,1,100);

DBMS_OUTPUT.PUT_LINE(ERROR_NUM || ': ' || ERROR_MSG);

END;

/


You can call the above procedure as follows , for example to keep only the only last 30 days of metrics within the

perfstat schema:


SQL> exec PERFSTAT.USP_SNAPSPURGE(30);


As the Perstat User Setup a database job to periodically purge the stats pack schema , for example to purge the statspack

metrics every 31 days , keeping only 30 days worth of metrics:

DECLARE jobno number; BEGIN DBMS_JOB.SUBMIT(job => jobno, what =>

'PERFSTAT.USP_SNAPSPURGE (30);', next_date =>

to_date('14-May-2008 03:00:00 PM','dd-Mon-yyyy HH:MI:SS AM'),

interval => '/*31:Days*/ sysdate + 31'); END;

/



Monday, May 12, 2008

Error Code RMAN-20011: target database incarnation is not current in recovery catalog

RMAN-20011


RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of configure command at 05/12/2008 18:21:50

RMAN-06004: ORACLE error from recovery catalog database:

RMAN-20011: target database incarnation is not current in recovery catalog


Details:


The above error occurs when the Database target Incarnation is not current in the Recovery Catalog.


The incarnation of a database is a number that is used to identify a version of the database.
A database incarnation is created whenever you open the database with the RESETLOGS.

V$DATABASE_INCARNATION displays information about all database incarnations. Oracle creates
a new incarnation whenever a database is opened with the RESETLOGS option. Records about the
current and immediately previous incarnation are also contained in the V$DATABASE view.


To Reference the corresponding Incarnation information in the recovery catalog review the

RC_DATABASE_INCARNATION and RC_DATABASE views.


RC_DATABASE_INCARNATION lists information about all database incarnations registered in

the recovery catalog.


RC_DATABASE lists information about the databases registered in the recovery catalog.

It corresponds to the V$DATABASE view in your target database.


Solution:

Connect to the RMAN schema as rman user e.g.


$ sqlplus rman/rman@RMANREP

SQL> select DBID, NAME, DBINC_KEY, RESETLOGS_CHANGE#, RESETLOGS_TIME

from rc_database_incarnation where dbid=2131079213;

DBID NAME DBINC_KEY RESETLOGS_CHANGE# RESETLOGS

---------- -------- ---------- ----------------- ---------

2131079213 DATABASE 1274431 80473525 20-JUN-07

2131079213 DATABASE 1274433 80251948 18-JUN-07


Connect to the RMAN catalog from the target databse

$ rman catalog rman/rman@RMANREP target sys/manager@DATABASE

Reset the database to the latest incarnation

RMAN> reset database to incarnation 1274431;

database reset to incarnation 1274431


Resync the catalog

RMAN> resync catalog;

starting full resync of recovery catalog

full resync complete


Verify all changes

RMAN> list incarnation;

starting full resync of recovery catalog

full resync complete

List of Database Incarnations

DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

------- ------- -------- ---------------- --- ---------- ----------

1274430 1274433 DATABASE 2131079213 PARENT 80251948 18-JUN-07

1274430 1274431 DATABASE 2131079213 CURRENT 80473525 20-JUN-07