Tales From A Lazy Fat DBA

Its all about Databases & their performance, troubleshooting & much more …. ¯\_(ツ)_/¯

Archive for November, 2013

RMAN-06900/RMAN-06901 and ORA-19921: maximum number of 64 rows exceeded

Posted by FatDBA on November 22, 2013

Received one of the odd and obscure RMAN/ORA errors of its kind While trying to connect with RMAN in Red Hat Enterprise Linux 5 and have wasted almost several minutes of my precious time, until i realized that there is one old RMAN session alive and was connected from the another terminal and was one day old before getting this error.

Okay so here is the case, while trying to connect with the target database in RMAN we have started recieving several RMAN and ORA errors …

[oracle@prashant1 ~]$ rman target /
Recovery Manager: Release 10.2.0.1.0 – Production on Fri Nov 22 21:30:38 2013
Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database: QRCL (DBID=859215136)
RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row
RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows
ORACLE error from target database:
ORA-19921: maximum number of 64 rows exceeded

RMAN> host;

Let’s explore more aboput the ora error using my favorite utility OERR

[oracle@prashant1 ~]$ oerr ORA 19921
19921, 00000, “maximum number of %s rows exceeded”
// *Cause:  The maximum number of rows in the V$RMAN_STATUS or V$RMAN_OUTPUT
//          table has been exceeded.
// *Action: Close some of existing and unused RMAN connections and sessions.

Let’s check how many and how old the rman sessions exists in my database.

[oracle@prashant1 ~]$ ps -ef|grep rman
oracle   25970 25861  0 Nov21 pts/1    00:00:50 rman target /
oracle   29999 29863  0 21:30 pts/4    00:00:00 rman target /
oracle   30113 30088  0 21:33 pts/4    00:00:00 grep rman

[oracle@prashant1 ~]$ date
Fri Nov 22 21:34:05 IST 2013

Alright, so there is one of the session with OS ID – 25970 running from November 21 from Terminal (tty 1) –
Let’s kill the session and try to connect with the Recovery Manager once again.

[oracle@prashant1 ~]$ kill -9 25970

[oracle@prashant1 ~]$ ps -ef|grep rman
oracle   29999 29863  0 21:30 pts/4    00:00:00 rman target /
oracle   30115 30088  0 21:34 pts/4    00:00:00 grep rman

Okay, so it’s gone and no more under the process list.

[oracle@prashant1 ~]$ rman target /
Recovery Manager: Release 10.2.0.1.0 – Production on Fri Nov 22 21:34:15 2013
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
connected to target database: QRCL (DBID=859215136)
RMAN>

Okay and we have not getting list of those errors what we previously encountered and issue is F.I.X.E.D

Hope That Helps
Prashant Dixit

Advertisement

Posted in Advanced | Tagged: , | 1 Comment »

‘Weird’ Error with Oracle’s “Log Errors” potentiality: — PL/SQL: ORA-00972: identifier is too long

Posted by FatDBA on November 20, 2013

Going to discuss one of the uncanny situation faced by me couple of minutes ago on one of my Test Machine. (Yes!, work on Vacations as well 🙂 )

One of the coolest features introduced in Oracle 10gR2 is the ability to log errors in large DML commands such as
“INSERT INTO table_name SELECT ….”.

One silly scenario I just came across while implementing the following.
I wanted to create an error log on a table who’s name is 30 characters long

PRASHANT.DIXIT_DEV07> BEGIN
2        DBMS_ERRLOG.CREATE_ERROR_LOG(‘MYREALLY_LONG_TABLE_NAME_HERE’);
3  END;
4  /

PL/SQL procedure successfully completed.

This command created an error log table named “ERR$_MYREALLY_LONG_TABLE_NAME” (note that the “_HERE” has been removed).
I then tried to compile a stored procedure that had a command like the following

“INSERT INTO MYREALLY_LONG_TABLE_NAME_HERE (cola, colb)
SELECT a, b FROM ….
LOG ERRORS
REJECT LIMIT UNLIMITED”

No luck, I get a “PL/SQL: ORA-00972: identifier is too long” error when trying to compile.

Looking through metalink and Google didn’t help much, so I then tried supplying the name of the error log table to the DBMS_ERRLOG.CREATE_ERROR_LOG procedure, once I did that I had to modify the “INSERT INTO” command to tell it where to log the errors.

Note the “INTO [schema.]table” section below.

LOG ERRORS [INTO [schema.]table]
[ (simple_expression) ]
[ REJECT LIMIT  {integer|UNLIMITED} ]

In a nutshell, I guess Oracle is smart enough on the creation of the table to truncate the error log table at 30 characters but it’s not smart enough yet when actually using the “LOG ERRORS” feature.
I haven’t checked the same in 11g and until then I’m going consider using the “INTO” clause as a best practice when using the “LOG ERRORS” feature.

Hope That Helps
Prashant Dixit

Posted in Uncategorized | Leave a Comment »

Standby/Dataguard:– RFS Process not working.

Posted by FatDBA on November 12, 2013

Not feeling well today!! 😦 , but as  It’s been a long time since i wrote my last article on Oracle database issues … here i am back again with one of the problem that we faced in our production database of our erstwhile customer, some time ago.
It was a typical Physical Standby environment with Maximum Performance model set. This is a story happened on one fine day when we started receiving some issues after a small network outage which blocked the redo stream to transfer logs from Production to standby server. ** * The bad part was  – the issue had happened during peak hours where we had confined amount of time to rectify the case.

Issue: RFS Process not working
Problem Description:
The filesystem containing the archive destination in DR server was not accessible. As a result the log shipping got stopped. We deferred the log shipping in the production server. After the filesystem was back, we enabled the log shipping but the RFS process in DR server was not running…The problem occurred when the log 24717 was being shipped… When we queried

SQL> Select status, sequence# from v$managed_standby;

The status for MRP showed that it was waiting for gap…We then manually shipped the log file and then applied… When we enabled the shipping we found that the RFS process was still not started…..There were no error in the alert log of DR…We found a trace file in the production server with the following message..

tkcrrsarc: (WARN) Failed to find ARCH for message (message:0xa)
tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0xa)

So we thought that the issue is with the archiver process….

Solution:
Check whether the archiver process is available for shipping log files. You can identify this by querying V$ARCHIVE_PROCESSES view.
SQL> Select * from v$archive_processes;

The output have the following columns:
Process: Indicates the process number.
Status: This should be ACTIVE
Log Sequence: Log sequence number of the log that is being shipped by the archiver. If it is not shipping any log then it should be 0.
State: This should be IDLE if the archiver is not shipping any log. If it is shipping any log then its state is BUSY.

In our case we had two archiver process running.

The status of both the arch process is ACTIVE.
The log sequence of First arch process is 0 and its state is IDLE. Hence it is healthy. However the log sequence of 2nd arch process is 24717 and its state is BUSY.

This was interesting because the problem occurred when the arch process was transferring the log 24717. This log was then manually shipped and applied. But the process still shows that it was shipping the 24717 log…
So we thought of increasing the arch processes. We increased the arch process from two to four.
SQL> alter system set log_archive_max_processes=4 scope=both;

We queried the v$archive_processes, the 3rd and 4th arch process was ready to ship the log files 24718 and 24719 logs respectively with their corresponding state as IDLE…
We enabled the log shipping and the RFS process in DR was started and the log shipping went smoothly.

However the 2nd arch process still was showing the same log sequence (24717) and state (BUSY)…. We then killed that archiver process…. And we were all good!

Hope That Helped
Prashant Dixit

Posted in Advanced | Tagged: , | 5 Comments »

 
%d bloggers like this: