RE: Interesting topic in linked in
Date: Mon, 11 Mar 2013 21:54:10 +0100
Message-ID: <5A25A252E6111747ADBF7904B67E9DCA01A7C58BC99B_at_MAILSERVER2.itdeusto.local>
Dataguard is your friend:
- Use some big delay (2 days ?. Test archivelog apply speed)
- Use different room/site that prod!
- Monitorize with a pair of scripts.
- Activate it periodically.
...and you will sleep better.
and more:
- Can use as read-only database, or rw with Active Dataguard.
- Can use DG server to run other test/dev instances.
- Can use DG to recover table or database to a precise instant of time, between your delay configured time.
-----Mensaje original-----
De: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] En nombre de dimensional.dba_at_comcast.net
Enviado el: domingo, 10 de marzo de 2013 3:33
Para: andrew kerber
CC: cicciuxdba_at_gmail.com; oracle-l; Gerwin Hendriksen
Asunto: Re: Interesting topic in linked in
As to the problem:
Bad things happen to good people. As a DBA you could have done everything right and been hit by a triple tap failure. We all do a lot of work designing our systems to survive double tap failures but as always sometimes you are just unlucky (Murphy lives and he will someday visit you too.). If he had backups and the the Backup admin basically expired backups in the pool which included your current backups because they were running out space and simply screwed up in their selection window, (Yes I have had it happen to me), then if you are running a database without a standby because everyone believed the SAN vendor that they never lose data or never fail, but then they do. You have now somehow lost your production database and your only normal means of recovery, your backups. Viola a database with a missing system data file (only missing of course if it was the inode/superblocks that were corrupted by the SAN and an attempt at repair didn't work assuming you knew to even try a repair versus just seeing that a file was missing and went searching for a replacement (although I have had a DBA rm a file in the live running db directory because of standard cut and paste error between two windows)).
Shit happens or in a lot of cases humans break your unbreakable system because humans were not listed as a potential failure point in the formula. When it happens to you, then you may even reach out to others with a desperate and unlikely request.
DUL works to point. As always for features and existing patch sets, there can be some minimal loss of data.
The other tool mentioned DUDE works fine with more potential loss of data.
Everything works best if you have the system table space to understand the last state of the system and extract all the important metadata stored there if you don't have it stored else where or it can not be easily reconstructed.
It is possible to recreate a system table space and stitch the database back together while having missing metadata to make it a perfectly working copy versus you just absolutely need to get at the data. There are many caveats especially when encryption and compression are in use, (Meaning the task gets harder with the more Oracle features in use layered over the top that you have to deal with in an unnatural recovery situtaion.)
There would need to be a really good reason to use that methodology, versus using the other two tools with some manual human double checking of the potentially lost data for alternate retrieva l of that data and using both tools for double checking the overall work where possible.
Matthew Parker
Dimensional DBA
- Original Message -----
From: "Andrew Kerber" <andrew.kerber_at_gmail.com>
To: "Gerwin Hendriksen" <gerwin.hendriksen_at_gmail.com>
Cc: cicciuxdba_at_gmail.com, "oracle-l" <oracle-l_at_freelists.org>
Sent: Saturday, March 9, 2013 1:05:47 PM
Subject: Re: Interesting topic in linked in
Yes, I have read about DUL. I have never used it though. It would be
interesting to know why he doesnt have a backup of the system tablespace.
I was thinking that the variations on re-creating the controlfile would not
help since you would still be missing the extent and data dictionary
information. Its kind of an interesting topic on a slow Saturday for an
Oracle geek:
Here is the link on LinkedIN if someone wants to help the guy:
Its interesting that this is the senior dba group in theory, but I have
seen some rather basic questions there.
On Sat, Mar 9, 2013 at 2:25 PM, Gerwin Hendriksen <
gerwin.hendriksen_at_gmail.com> wrote:
> I guess if your system tablespace is not complete due to the fact you are
> missing one of its vital files, your only good option would be thinking of
> a tool like DUL. This is a link to a small description of it:
> http://www.joords.nl/index.php?file=kop12.php
>
> Anyway it has been a very long time ago I actually did something with DUL
> but probably there are who have more recent experience. Good luck!
>
> Regards, Gerwin
>
> Verstuurd vanaf mijn iPhone
>
> Op 9 mrt. 2013 om 20:34 heeft Guillermo Alan Bort <cicciuxdba_at_gmail.com>
> het volgende geschreven:
>
> This is just off the top of my head... and it probably won't work. But you
> could create a blank DB and then recreate the controlfile including all the
> DFs from the other DB. The DB Name should be the same, and I don't know if
> you can force a DB ID at database creation, otherwise it might not be
> possible. Or if you can change the dbid of the other datafiles.
> An SR with Oracle would be ideal, they've helped me with some weird
> recovery scenarios with hot copies of the DFs without enabling backup mode
> and stuff like that.
>
> I'll add this to the next DRE we perform...
>
> Also, while updating the resume is a sound advice, I would suggest that if
> asscovering is required he look into the reason for there not being a
> backup. I've often found that the reason for most unrecoverable databases
> are manages who don't want to "waste" money or storage in backups.
>
> hth
> Alan.-
>
>
> On Sat, Mar 9, 2013 at 4:21 PM, Andrew Kerber <andrew.kerber_at_gmail.com
> >wrote:
>
> Someone on LinkedIn is asking how to start the db when system01.dbf is
>
> missing and there is no backup. Interesting topic, but for the life of me
>
> I can't think how it can be done. There are some suggestions on how to
>
> retrieve the data.
>
>
> My own suggestion was to update the resume, but I am curious if anyone has
>
> ever managed to do this, and if so, how?
>
>
>
> Sent from my iPad--
>
> http://www.freelists.org/webpage/oracle-l
>
>
>
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- Andrew W. Kerber 'If at first you dont succeed, dont take up skydiving.' -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Mon Mar 11 2013 - 21:54:10 CET