Re: Help! 9.0.2 dead!

none wrote:
> Here is some sql output:
>
> SQL> select * from v$log;
>
> GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
> ---------- ---------- ---------- ---------- ---------- ---
> ----------------
> FIRST_CHANGE# FIRST_TIM
> ------------- ---------
> 1 1 254 104857600 1 NO INVALIDATED
> 32176128 18-AUG-05
>
> 2 1 252 104857600 1 YES INACTIVE
> 31619872 15-AUG-05
>
> 3 1 253 104857600 1 YES INACTIVE
> 31897856 17-AUG-05
>
>
> SQL>
>
> Listener and the database are starting in services, the DB is mounting
> at least.....
>
> http://www4.ncsu.edu/~tpcolson/alert_hydro.txt
>
> yes, archive logging is enabled, and every single archive log since
> install date is available. I'm thinking though, that I should not use
> the archive log files for the "crash date" (aug 18) and the day before?
> The data I'm interested in hasn't been edited since late july.

If you don't have a backup of your datafiles your archived logs will get you nowhere. Think about it: in the archivelogs there are the changes recorded that were made to your data. If you don't have anything to start with, you're basically toast.

Now there is a technique that let's you even recover if you don't have a backup of your datafiles, but that requires that the database was in archivelog mode prior to the creation of the datafiles in question.

Unfortunately, this doesn't work for the system tablespace for hopefully self evident reasons, so we're back to where we started: without a backup of your datafiles, you're toast.

Recovery is something you plan for, you test. Backup is only the preparation for that.

If you've got support, then call them. They might be able (although possibly at additionaly costs) to extract the data from what is left. If you don't have support..... (you don't want me to repeat it, do you?).
>
> as far as my backup strategy goes....I think I've got enough grief on
> that, lesson learned. Needless to say, I'm out of the DBA business, I
> shouldn't be doing this in the first place, not enough time to plan
> field work, teach class, walk the dog, and sleep.....This was never
> intended to be a production server, but it worked so well we somehow
> started relying on it....
>
>
> "Files don't disappear like that, even on Windows :-)". See pervious
> post about suspicious malicious activity. The renaming of the guest
> account to "owned" is my first clue.....
>
> No faulty disk. This is all on a Raid 10 array. They all check out.
>

And because of RAID 10 someone thought that proper multiplexing redo logs isn't necessary, too? If you dig a hole deep and wide around you,sooner or later you fall into it, I'm afraid.

Sorry
Holger Received on Thu Aug 25 2005 - 08:18:23 CDT