When I do a backup control file to trace it goes to bdump folder on a database, but to udump folder on the other database.
Can somebody explain that?
Either Oracle is mistaken or you are.
I bet Oracle better reports reality than you.
If you think that Oracle is doing the wrong thing, then file a bug report with MOS.
What command are you running and what is the location of your bdump and udump?
I agree with user846411 this is most likely due to the command being used as the BACKUP CONTROLFILE clause includes the ability to name the trace file. Plus you should check the database parameters for background_dump_dest and user_dump_dest which can be set to use the same directory or difference ones.
HTH -- Mark D Powell --
Before you backup the controlfile to trace:
Find out the name of DB. Select name from v$database; find out dump location.
Can you show the exact commands that you are firing on both databases?
Does your alert log have a message about where it is going? I've seen some odd behavior on 10.2.0.4 where a backup controlfile creates it where it says, then some time later it disappears. I wound up copying it elsewhere right after creation. But the backup to trace right after it works fine. Very puzzling.
If your connection is a Shared Server (aka "MultiThreaded Server"), a trace file is written to the bdump. Dedicated server connection trace files go to udump.
Hemant K Chitale
First, thanks to all.
I have several databases in this server and all background_dump_dest are set to bdump.
One database behaves differently. When I do ALTER DATABASE BACKUP CONTROLFILE TO TRACE; it does not create a new trace file in the bdump folder, it just appends the output to an existing trace file.
When I do the same thing on other databases they will create a trace file in bdump folder and store the backup control in there.
Any help is appreciated.
>When I do ALTER DATABASE BACKUP CONTROLFILE TO TRACE; it does not create a new trace file in the bdump folder, it just appends the output to an existing trace file.
The trace file would go to user_dump_dest not background_dump_dest. If a file already exists with the same name as it expects to generate, Oracle *will* append to the file, not overwrite it.
Hemant K Chitale
Thank you for your responses.
I haven't got my question resolved yet.
I have 16 databases. I tested them all and started confusing.
I deleted all trace files in udump and bdump, then did:
alter database backup controlfile to trace;
A new trace file was created in bdump and it contained CREATE CONTROLFILE in formation.
I renamed this file like bkctl_TRDA.trc and alter database backup controlfile to trace again. A new BK control file was appended to bkctl_TRDA.trc
I moved bkctl_TRDA.trc to another location and alter database backup controlfile to trace again, nothing happened. nothing in bdump, udump. Only showed the command in the alert log.
I tested on another DB on the same server, it happened the same.
I also tested some DBs version 10.2.0.5.0, the results were the same.
So my conclusion is if I run this SQL command a few times then the database will not backup the control file. It only does in the first couple of times.
No, you should log out and login again to create a new session. If you issue the ALTER DATABASE BACKUP CONTROLFILE TO TRACE from the same session again, Oracle attempts to write to the same trace file again. The move in Windows may have different locking behaviour when Oracle attempts to write to the same trace file.
The trace file names are curious. Did you use ALTER SESSION SET TRACEFILE_IDENTIFIER ?
Hemant K Chitale
I just logged in and issued ALTER DATABASE BACKUP CONTROLFILE TO TRACE but it didn't do anything. Then I issued ALTER SESSION SET TRACEFILE_IDENTIFIER = "MY_TEST_SESSION" then backup control file again and it worked.
Thank you Hemant.