I have not seen a 200GB db but have some clients with about 150GB, but I suspect dump/load will take a very long time. You should have a beefy SQL server to manage with that load.

Look at the Tairox products (www.tairox.com/products-overview.html), they have some db tools.

The CEO of Tairox is Don Thomson who co founded Accpac and has a long involvement with the product, the Tairox products are of the best quality.

We have a site that has a production SQL db 390GB in size, currently.  haven't dumped that one for a while, so don't have a time estimate.  we do a full SQL backup nightly which is then uploaded to a cloud backup site.  Agree with Ettienne about the TaiRox Fast DB Tools, you'd need a beefy SQL server and those tools to handle it efficiently.

just curious -- why would anyone even want to use dump and load for a database that size?  why not just use the sql backup?

People do strange things ;)

Like using dump/load as a backup.... which it definitely is not.

Ok, just what I suspected. :-)  

Largest DB I manage is about 100GB, it has not been dumped/loaded in a few years, there is no need to if you have the proper maintenance plans in place.  

Dear All,

Thanks for the input. Basically the dump load is not use for backup. But found out some unsual things going on in the accpac like slower day end, or not responding. Also some other posting issue in modules. So would think to consider doing dump/load to get a refresh.

Did test to dump/load for several times, and it always get stuck on a different tables. Dont know why still trying to figure out the issue.

Dear All,

Thanks for the input. Basically the dump load is not use for backup. But found out some unsual things going on in the accpac like slower day end, or not responding. Also some other posting issue in modules. So would think to consider doing dump/load to get a refresh.

Did test to dump/load for several times, and it always get stuck on a different tables. Dont know why still trying to figure out the issue.

Dump/load will not fix anything, you will be wasting your time. Look at your SQL server resources, you will need a lot of RAM (64GB+) and CPU to manage that size db. Your SQL server will have to be dedicated to SQL only, nothing else running on that server.

you might also check drive space where your data, logs and tempdb files reside ..

Hi,

Just to update on the status of this database, I managed to rescue the db but only by creating a new sql database with a different name and then do a dbload onto it and now it is working fine. Customer using the SSD Disk , the loading took about 1 day time to process. Thanks for all the input and comment