True purpose of Catalog.DB?

[that1guynick]

We've recently reconstructed our database schema from the ground up, and when it was installed, the one installing enabled this option.

We use a local SQL2k5 asdb instead of the Brightstor model.

My question is: What is the purpose of the catalog? And is it just duplicating information that is already kept in the SQL asdb?

Thanks!

 

[vschumpy]

No, it is the exact opposite. Using catalog.DB means that detail information is NOT automatically merged to the database after a backup, but is held ready in case it is needed.

This has benefits in that :

1 Your DB doesn't get unwieldingly large - which is VERY easy these days especially if you are using multiplexing, NAS, or the Exchange Document Level Agent.

2 You don't have the disk channel hit and/or CPU spike when merging detail information to the DB at the end of the backup job.

3 Less time is spent maintaining the DB (although this is usually a lot less with SQL anyway).

4 Usually you end up saving a boatload of disk space.

If using catalog.DB then only summary information is merged to the DB automatically - ie session numbers and session names. If required, the detail information can then be merged automatically from the .CAT file on disk on-the-fly if needed.

To break it down, think of the .CAT file as a compressed version of the detailed information that is expanded/merged into the database. The expanded detail information can often be many times larger in the DB, than the actual physical size of the .CAT file itself.

 

[that1guynick]

vschumpy,

Thanks for the reply.

Out of everything you listed, and a few of the warnings posted, they are not really issues to be concerned about.

My SQL database (asdbdat) is 120MB, while my Catalog.DB folder tree encompasses 1.2GB. This only includes the 14 jobs that have run since the rebuild over the course of this week.

I dont think we used the Catalog.DB in the past because one of the reasons for rebuild was that the database had grown to upwards of 135GB, but then again, no one had any SQL Maintenance setup. I have now set up the maintenance to the exact 'T' as specified in a certain SupportConnect document I found. It seems to be running fine, but not really trimming anything because there is not enough history yet.

I guess my question is, will the SQL database method do everything that the Catalog.DB can/will do? And, if so, can I just uncheck the catalog option in the global config and rename/delete/move those directories?

This is on a beefy server, so Im not really that concerned with performance. It can handle it.

Thanks again for your help. Im a Backup Exec guy by trade, and was thrown to the wolves with this at this new company.

-Nick

 

[vschumpy]

Nick, it really would depend on your backup strategy and rotation, and a little understanding of relational databases helps here too.

Maintenance, whether it be SQL or ARCserve's own database will only trim what has passed the prune retention time (by default 30 days), but the prune job doesn't necessarily remove what you think it might or should.

More often than not it is only removing the references or pointers to the original information (there is a really long explanation into how it does work, but it's really won't add too much to this).

It's difficult to say how big your database could be without knowing what sort of stuff you are backing up and even then it would be a pure guess with no logic whatsoever. From experience it's a guess that 1.2Gb of CAT files could easily translate to 4-5 times that size if merged into the DB.

One thing to remember is that if you are using the catalog.db, then the CAT files are also pruned by the prune job as appropriate (if you're using at least r11.5) - I think that was the first version to automate this.

If your DB is likely to grow to 135GB even on a well specified, or even dedicated host/SQL Server it's something I would still personally avoid if possible - unless of course you frequently have to do urgent restores within a specific SLAs, or to conform to regulatory legislation.

Once the DB starts getting that big, the queries that the ARCserve application passes to SQL can be somewhat intensive and you could argue the DB requires some design rework to scale to anywhere near that size.

Should you get an error when the DB is that sort of size, or timeout even then this can start affecting your backups (media pools/rotations), and also things like inventory of your library (ARCserve references the DB when reading/storing media). This may show up rather obscurely as SCSI timeouts. Something you'd potentially only see if you were running an SQL trace at the same time as the library operation.

If you get some time check out this document:

http://supportconnect.ca.com/sc/redir.jsp?reqPage=search&searchID=TEC342813

It will give you a better insight into how ARCserve communicates with hardware, which is very different to what you're used to with BE. This is one of the things I always find people coming from using BE have a hard time getting past until they understand the differences in how hardware is handled.

Anyhow - good luck in converting - personally I've never used BE myself, but I have helped a few people convert to the ARCserve way of thinking through the years - it ain't gonna be easy - but hang in there and hopefully you'll see some benefit soon.

 

[that1guynick]

While I DO love a good chat about different technologies, I think we may be delvinga bit too deep into this.

Taking a step back for a second, we have BE running at all other sites, but BAB is still running our corporate office, and has been for 5-6 years. Our maintenance with BAB just expired so we're looking to finally license BE for the final site.

That said, we still need to use this software for another 6 months to maintain the ADIC libraries and the jobs we've created.

So, with that said, and not getting way too deep into the inner workings of BAB, I guess what I am looking for is some assurance that I'm doing things the best way I can with BAB. I'll give you a bit of a rundown of what we have, and if you're interested, maybe you can tell me I'm doing things right and to leave it alone, or make some suggestions on how to do things differently. Again, we're in the very beginning stages of rebuilding this so changes are fairly simple.

BAB 11.5
**Remote Agent
**Open File Agent
**SQL Agent
**DR Option
**Tape Library Option

We run an ADIC-100 with 2 drives and 30-some-odd tapes, in two groups (0 & 1). Group 0 is all odd tapes, Group 1 is all evens.
We run two jobs simultaneously to each respective Group/Drive backing up some 25-ish servers, SysStates of each, and all SQL instances if present on a server.

Total data looks to be around 600-700GB and takes 4 tapes per night, running full backups, usually takes about 10 hours.

We opted for a local SQL2005SP1 installation for database mgmt over the Brightstor native, and about the only thing we've changed is checking the Disaster Recovery option and the Catalog Option in the Global Config. I also have a Once-Weekly Maintenance within SQL2005 Studio running on the asdb database, which hasnt changed in size since recreating everything.

Thoughts?