(Resolved): Another 11g enigma
Date: Fri, 26 Aug 2011 08:48:19 -0800
Message-ID: <4E57CE53.40605_at_alaska.edu>
Thank you to Charles Schultz!!!
A while back there was a thread about issues with the alert log. One detail that I remembered from that thread was that there were issues with the alert log that sometimes gets created in $ORACLE_HOME/dbs. We occasionally have alert logs created in $ORACLE_HOME/dbs, but they always seem to be generated at database startup or shutdown, though I haven't paid much attention to the exact situation. When I do find these alert logs, I check them out and then delete them since they're usually old.
Surprisingly enough, I found an alert log for the cloned database in $ORACLE_HOME/dbs and it didn't contain the expected information...it had information for an old ORA-00600 incident...from July.... I deleted that alert log, ran utlrp in the cloned database and the message got written to the alert log in the diagnostic_dest directory, and the trace file that got generated didn't have any errors in it!!!
It's Friday, life is good!
- Maureen
Maureen English wrote:
> For those of you who may be a bit bored today....
>
> We clone our production database to another database about 3 times a year.
> We have a script that we've used for many years, starting with 8i
> databases.
> The script has been modified over the years to accommodate changes with the
> upgrades.
>
> Basically, we just copy the datafiles and log files to the new location,
> rename them because they all contain the database SID in their name, create
> a new parameter file and control files and voila, we have a copy of the
> database. We then go in and modify certain bits of data and passwords so
> that users can access the application.
>
> I recently found a problem with our method. There are tables in the
> database
> with information that is SID specific. Information like DATA_PUMP_DIR
> isn't
> a big issue because we change that. Information in V$DIAG_INFO is
> correct for
> the cloned database. However, even though some information, like log
> rolls,
> is written to the text version of the alert log, other information, like
> alter
> database commands, is not written to the text version of the alert log.
> The
> xml version of the alert log has everything in it and looks fine when
> viewed
> with adrci.
>
> When we execute alter database commands, we get trace files generated
> with the
> information that would normally go to the trace file, as well as messages
> that it can't write to the text version of the alert log:
>
>> ** DBGRL Error: Text Alert Log >> ** DBGRL Error: SLERC_OERC, 48934 >> ** DBGRL Error: >> ** DBGRL Error: ALTER DATABASE CREATE STANDBY CONTROLFILE AS >> '$HOME/tmp/TEST_Standby.ctl'
>
> It looks like there is some value in the database that isn't quite
> right, but I'm
> having a hard time finding it....
>
>> > oerr ora 48934
>> 48934, 00000, "invalid input for the file name identifier"
>> // *Cause: An invalid input was given for the file name indentifier.
>> The // file name is not allowed to have slashes ('\', '/') and
>> is not
>> // allowed to refer to the parent directory using the '..'
>> characters.
>> // *Action: Check the file name and provide a valid input.
>
>
> I do have a ticket in with Oracle, and this doesn't seem like an
> emergency, but
> it sure is confusing....
>
>
> - Maureen
>
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Aug 26 2011 - 11:48:19 CDT