Re: all time worst question I have been ever asked as a DBA

  • From: David Fitzjarrell <oratune@xxxxxxxxx>
  • To: "Marco.Gralike@xxxxxxx" <Marco.Gralike@xxxxxxx>, "Stephens, Chris" <Chris.Stephens@xxxxxxx>, "andrew.kerber@xxxxxxxxx" <andrew.kerber@xxxxxxxxx>, Oracle-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 27 Jul 2011 13:29:56 -0700 (PDT)

Back to the original topic -- it wasn't a question so much as a statement:
 
Them: "I've been reading and exports take up less space than backups, so we'll 
do those instead.  Oh, and shut off this archivelog stuff, that will save disk 
space."
Me: "You can't do point-in-time recovery if I shut off archive logging and only 
perform exports."
Them: "Why not?  You do the export at the end of the day and we're good."
Me: "That won't capture batch-processed data."
Them: "We can rerun the batch.  Do as I ask."
 
I did.  Several weeks later a hardware failure lost the database and they 
could only restore from the most recent export and, as expected, the batch jobs 
needed to be rerun and all user transactions  had to be re-entered.  The RCA 
revealed the above conversation.  You can guess who remained and who didn't.

David Fitzjarrell


From: Marco Gralike <Marco.Gralike@xxxxxxx>
To: "Stephens, Chris" <Chris.Stephens@xxxxxxx>; "andrew.kerber@xxxxxxxxx" 
<andrew.kerber@xxxxxxxxx>; Oracle-L <oracle-l@xxxxxxxxxxxxx>
Sent: Wednesday, July 27, 2011 10:26 AM
Subject: Re: all time worst question I have been ever asked as a DBA


BTW 

I also never use those file extensions anymore, but then again DBCA still has 
that practice and I would not be surprised if it turned up in OCP manuals etc.
I once created an enhancement request saying that "this new APEX core 
directory, regarding naming is probably not a good idea to implement". 
They didn't get the point, or I didn't got my point across, that old unix admin 
methods / people (maybe still also on linux nowadays) have a practice to delete 
from time to time core files and core directories on their filesystems…


From: "Stephens, Chris" <Chris.Stephens@xxxxxxx>
Date: Wed, 27 Jul 2011 17:02:52 +0200
To: Marco Gralike <marco.gralike@xxxxxxx>, "andrew.kerber@xxxxxxxxx" 
<andrew.kerber@xxxxxxxxx>, Oracle-L <oracle-l@xxxxxxxxxxxxx>
Subject: RE: all time worst question I have been ever asked as a DBA


Which is the #1 reason I no longer allow redo logs to end in ‘.log’! J
 
I have that as a check implemented in a procedure that runs each night to 
ensure every database in our environment complies with a few standards that I 
don’t consider to be debatable.
 
From:oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Marco Gralike
Sent: Wednesday, July 27, 2011 9:57 AM
To: andrew.kerber@xxxxxxxxx; ORACLE-L
Subject: RE: all time worst question I have been ever asked as a DBA
 
Be happy that he asked. Sometimes they just delete log files because they need 
the space.
Van:oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] namens Andrew 
Kerber [andrew.kerber@xxxxxxxxx]
Verzonden: dinsdag 26 juli 2011 21:38
Aan: ORACLE-L
Onderwerp: all time worst question I have been ever asked as a DBA
So, I am getting this error on one of our virtual Linux servers:

ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/datafiles/devdb/control01.ctl'
ORA-27086: unable to lock file - already in use

Its probably due to a stale NFS lock.  The question from my sys admin:
-rw-r----- 1 oracle oinstall 10076160 Jul 22 13:33 control01.ctl
can that file just be removed



Ok, I am a little frustrated with him...

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'
CONFIDENTIALITY NOTICE:
This message is intended for the use of the individual or entity to which it is 
addressed and may contain information that is privileged, confidential and 
exempt from disclosure under applicable law. If the reader of this message is 
not the intended recipient or the employee or agent responsible for delivering 
this message to the intended recipient, you are hereby notified that any 
dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this communication in error, please notify us 
immediately by email reply.

Other related posts: