tar crashed oracle

[CJENSEN_1]

I was doing a tar on my controlfiles and redo logs (as a test) while the database was running. It caused the database to crash. The alert log mentions a corrupt block relative... and so on. My question about TAR - does unix do something with the file during the TAR process that prevents Oracle from using the file? Just curious. We are using fbackup/frestore, but are looking at tar to do some incrementals.

[Ross Zubritski]

I appears that tar "locked" the control file. tar was never meant to be a "open file" backup solution.

Regards,

RZ

[Patrick Wallek]

As far as I know tar does not lock a file. It just reads it.

I was tar'ing up some files today and had a file change size while I was tar'ing it.

I would not really suspect tar. I suspect it may have just been a case of bad timing.

[Ross Zubritski]

Good info Patrick

Was the file that changed bin or ascii? I can see tar handling an ascii file on the fly, bin is another story.

Just my 2 cents.

RZ

[Patrick Wallek]

It was an binary file. In fact it was one of Measurewares data files in /var/opt/perf/datafiles/log*.

[Ross Zubritski]

Ah, the myteries of Oracle ;)~

[Ross Zubritski]

The plot thickens.. An oracle control file changes each time time SCN (transaction) number changes, this could be nanoseconds. The files in the perf directory changes based on the time you set for data collection, i.e. 5, 10.

Just my 2 cents once again,

Regards,

RZ

[Patrick Wallek]

That is true. I would still wonder if tar is the culprit here though.

I would be tempted to do a 'dd' on the disk that the LV is part of and see what happens. If it completes successfully, then maybe tar did do it. If not, you've got a disk going bad, which what I suspect.

[Ross Zubritski]

Excellent point sir.

[Stan_17 · Accepted solution]

Hi,

Just curious, why would you want to backup redo logs when the databases are open. never backup online redologs during hotbackup, cuz you might restore the backed up redolog file on top of current redolog thereby losing all the redo's that are not yet archived or not being checkpointed and you end up in-complete recoveries.

do not tar controlfiles too...use 'alter database backup controlfile to backup_location;' also, have ascii version of it 'alter database backup controlfile to trace;'

Stan

[A. Clay Stephenson]

Assuming this was a tar reading these files, that should have not caused your problem. Tar and cpio do absolutely no file locking. I think this was a case of "I was running tar; Oracle crashed." The technical term for this is called "coincidence" rather than cause and effect.

[Yogeeraj_1]

hi,

check the oracle alert.log. maybe you will have some clues about the crash there.

hope this helps!

Best Regards
Yogeeraj

[John Jayaseelan]

Hi,

I do not think tar will lock the file during the back or reason for the crash. Could be due to the oracle process. Better to check the log file for the further info.

John Jayaseelan

[Steven E. Protter]

tar should not have caused the problem, it does not lock the files.

Oracle may not have had the access level it wanted during the process, but this is probably an oracle problem.

You can not use fbackup for anything other than a cold, database down backup.

fbackup will try to lock the files on an open database, might hack oracle off and cause corruption. It will eventually fail to backup open database files resulting in error messages.

If you want to back up hot oracle databases, use rman. It comes with oracle and is a pretty useful and reliable tool.

You can also use omniback, over version 3.5 I think to get oracle 8.1.7 databaes. omniback also uses rman for oracle 8 backups.

If you choose this route, let me know, I can probably find and forward you a document on how to set up and use rman(I might have to mail it snail style it may only be here on paper)

If you mail, make the subject line relavent, I've been sick for two weeks and am nearly 100 emails behind schedule.
stevenprotter@juf.org
SEP

[Raynald Boucher]

Which was the exact tar command issued?

A bad tar command could cause Oracle to error. ex.:
tar -cvf control_file1 control_file2

would corrupt control_file1.

[Colin Jensen]

it was tav -cvf ... pls explain how this would corrupt it. Thanks.

[Ian Lochray]

In Raynald's example, control_file1 follows the "f" flag of the tar command so control_file1 would be the destination for the tar output. The example command would tar control_file2 into a tar image called control_file1, overwriting the control file.

[TwoProc]

The above posted message is right. The "c" in "cvf" means "create" and the "f" means "file" and the file you gave it was your control file. Basically, you turned your controlfile into a tarball. The correct syntax would have been "tar cvf /tmp/mynewtarfile.tar controlfile1 controlfile2". That would take both controlfile1 and controlfile2 and put them in the newlycreated file /tmp/mynewtarfile.tar.

[Colin Jensen]

It did create a .tar file, but also left the oracle files intact. Yes, the command entered was as in the last post.

[CJENSEN_1]

Thanks