Database Corruption, SQL, dbcheck, and dbfix

[GermanCowboy]

I have been using Arcserve since version 6 and have found help on this forum many times. Now it is my turn to pass on some information.

On Wednesday I called C.A. to find out how to move our VLDB database to and SQL server. We have been having problems every 6 weeks with the VLDB and it seemed like the thing to do. I should have taken the hint when the support person said we don'e have any documentation on that, but I will send you what I know via email. Well it worked.

On Friday I called back and asked why the database size wasn't growing. A bunch of questions and several screen shots being emailed, I got the "let me call you back" speech. He did. Obviously he was reading from something someone had typed for him and in the process I ran bconfig. WRONG THING TO DO!!

I spent most of the day getting the databases back to some sort of stable state (or so I thought) and set up the monthly backups to run last night. When backups fail, I have it set to email me at home. This morning there was the email.

I sat down at 7:47 a.m. with a cup of coffee and thought I had a simple database error. At 12:30 p.m. I finally realized that the dbfix and dbcheck will both return reports of no errors and still have a bad database. I had definite database errors from the SQL conversion. I don't recommend trying to do that. It's Saturday, so I decided to cut my losses, copy an empty database over and just merge tapes. We are using a file system, so it takes just a few minutes to configure the jobs. The Merge operations failed almost immediately, however backup jobs ran fine! Reinitializing the databases and running dbcheck and dbfix show no errors.

Finally at 12:30 that little nagging voice said to run a backup of something small and attempt a restore. The restore screen looked normal! Because of the nature of our data we normally do restores by session, not by tree. When I clicked restore by tree, I wanted to choke a programmer somewhere! The entire screen was jibberish and hence here is the problem that I had been fighting for almost 5 hours!

I took a good database from another server, copied it, initialized it, and all is now well. Just because C.A. says no errors found, don't believe it!!!

Another little tip is to save the jobs to disk. This creates a script of the backup job so if your boss is like mine and he deletes your backup job for you, it adds back in very quickly.

For the most part, Computer Associates has been very successful at taking a wonderful product and turning it into a piece of garbage!!!!!

Happy computing!

 

[mohamdr]

thanks for the info ....

 

[davidmichel]

dbfix, dbcheck, and all those utilites are for VLDB as in the name vldbutil.htm, so once the database is converted over to SQL there is no point in using them. SQL utilities have to be used to repair a SQL database, and not VLDB utilies.

The time to run those utilites is BEFORE the conversion is done. Start with dbcheck on all the databases and if there are any errors &/or inconsistancies then run dbfix, dchain, and keybuild.

Perhaps I'm missing something here "I took a good database from another server, copied it, initialized it,". Once the database is initilized it's blank so I don't understand what the point of converting it is.

Here is something else I don't understand "Just because C.A. says no errors found, don't believe it!!!"
CA says no errors???? What is that, the tech support person? the utilities? It does not make sense to me. If you are talking about the utilities then yes there can be no errors found but there can be inconsistancies which are still an inidication of corruption and needs to be fixed.

One last point is to express my own disapointment in what I found. You see when I read "Now it is my turn to pass on some information." I expected something along the lines of detailed instructions on how to do the conversion and not someone's rantings.

 

[GermanCowboy]

David,

Let me make a couple of clarifications.

I'll submit that reading it a couple of days later, it is somewhat of a rant, but it also points out some serious errors in Arcserve. You or anyone else is welcome to contact me at wmheid@earthlink.net with any specifics that aren't clarified in this post.

C.A. doesn't have any written instructions on how to convert a database to SQL. I received a "half written" email from their tech support.

Here is how I did it:

1. Built a new server with SQL on it and installed Arcserve. This will give you blank sql databases if that is what you choose during installation.

2. Then you go to Central Database configuration and add the server(s) as members that you want to add to the central database on the SQL server. The conversion is not complete at this point.

Now you are faced with a decision. If you keep a copy of the database on the remote server, the database will be kept in VLDB format, so therefore dbfix, dbcheck, etc will still work as I posted I had ran.

If you decide not to keep a copy of the database locally, it is converted to SQL and yes, the utilities are no longer valid and won't work.

Either way, the vldb databases still exist on the member servers. Full SQL conversion just doesn't do anything with them.

I have 7 backup servers running and moved 2 of them to SQL.

Because of the poor support received from many calls to C.A. I run dbcheck each and every weekend after the backups finished. I also ran it before the conversion, thank you.

Since the utilities ran "clean" and there were no inconsistences on any screens (did I mention I started with arcserve at version 6) or from any utilities, I don't understand your comment. There was simply nothing there.

Last but not least, I keep a spare set of empty databases and have for years. When I copied these over to the server in VLDB format to backout of the changes, Arcserve still refused to run that was the point of initializing it and converting an empty database. I say again, C.A. has no procedures for doing this conversion, that is from their web site and their tech support staff (2 different calls to 2 different people).

We have done the conversion of one server again using the steps above. I don't recommend the change. Our motivation is seeking stability of the database so that I don't spend a Saturday every 6 weeks building everything.

You are welcome to contact me at wmheid@earthlink.net with any comments, requests for information etc.

Wolfgang

 

[davidmichel]

So this is more than just a conversion from a VLDB to a SQL database. In your setup you can run with or without Central Database. To run without it each server would maintian it's own database in the SQL server running on the one system. If running in a SAN then Central Database is the way to go, otherwise it is up to personal preference.

I took a look online and found a doc from the 6.5 days. In the Admin Guide there is a paragraph that says to run dbtosql.exe. Running that instructs you to run setupSQL.exe which is the part of the installation program that creates the databases in the SQL server.

Your idea of keeping a copy of a blank clean database is a good one. It is the quickest way to start the database over when there are problems. While on the subject if you are in a DR situation or loose the SQL server the quick way back is to install with VLDB and then Recover the database.

 

[GermanCowboy]

I backed out the changes and reset the database to VLDB. In a weeks time it grew to 5 Gigs. It crashed and burned earlier today.

Went through the drill, copy over the empty database, initialize it to be safe, and run dbcheck.

Then I ran bconfig which picked up the empty database and converted it to SQL by following the screens.

The merge jobs are running and things seem OK. Time will tell if the move to SQL works or not.

 

[ludwigchin]

I installed ARCServe 11, to use the VLDB database.m, but many times the media information for a backup would not show up unless the database was restated. So i decide to use a SQL server as the central database instead.
I've run setupsql and created the asdb.dat, and aslog.dat files. i've run dbtosql, and the sql database files seem to be populated. under the database screen, in the summary, the *.dat files are shown as the local database. I've made the computer the central database, but i dont see any of my jobs or/media information. Any thought on how to fix this.

 

[mindsailor]

I've had similar issues with the Arcserve database over the years. I recently converted to the SQL database but I am not having an issue related to the media pools.

It seems that when some (but not all) of the media drop into the scratch set, they are no longer displayed on the media pool screen but I can select the scratch set and click on remove media and the media shows up in the remove media list. It is kind of like some of my media has some sort of "hide me from appearing in the scratch set" attribute. The backup jobs can not find the media when they are in this hidden state either.

I am not all that familiar with SQL server. Can anyone tell me what the SQL equivalent utilities are to the VLDB utilities. I think I may have some bad indexing in the database or maybe some corrupted records.

Thanks,
Bryan