Drop Table
Support Forum for database administrators and web based access to important newsgroups related to databasesHi all, I need some pointers on which direction to look in for a solution to a problem we are facing. We are running MBS Great Plains on SQL 2k (Win 03 server). Our DB is currently over 300 Gb and growing. Reporting work cannot be done on We are looking for a method to 'replicate' our DB to a secondary server to use for reporting and data warehouse work. Currently we are using Log Shipping to get updates to the 'Reporting' server, and while that mostly works, one of our reporting tools needs to be able to write to the DB and with Log shipping the DB is, of course, read-only. The other issue is that the DB is unavailable 3x daily while our T-Logs are restoring. I know that replication (SQL Native) was tried prior to the Log Shipping solution and was very unstable and 'broke' often. Unfortunately I don't have the details on the issues - I wasn't the person implementing the solution at the time. Does anyone have a similar situation or can offer suggestions on possible soltions? Thanks Meredith
Post Follow-up to this messageLog shipping doesn't sound like the correct solution in your case, since you need to have the reporting DB available. The two options would be to use replication or to populate on a schedule via a DTS/SSIS package. -- Tom ---------------------------------------------------- Thomas A. Moreau, BSc, PhD, MCSE, MCDBA SQL Server MVP Toronto, ON Canada . "mryan" <coffegrl@gmail.com> wrote in message news:1144087812.561168.94280@v46g2000cwv.googlegroups.com... Hi all, I need some pointers on which direction to look in for a solution to a problem we are facing. We are running MBS Great Plains on SQL 2k (Win 03 server). Our DB is currently over 300 Gb and growing. Reporting work cannot be done on We are looking for a method to 'replicate' our DB to a secondary server to use for reporting and data warehouse work. Currently we are using Log Shipping to get updates to the 'Reporting' server, and while that mostly works, one of our reporting tools needs to be able to write to the DB and with Log shipping the DB is, of course, read-only. The other issue is that the DB is unavailable 3x daily while our T-Logs are restoring. I know that replication (SQL Native) was tried prior to the Log Shipping solution and was very unstable and 'broke' often. Unfortunately I don't have the details on the issues - I wasn't the person implementing the solution at the time. Does anyone have a similar situation or can offer suggestions on possible soltions? Thanks Meredith
Post Follow-up to this messageI believe that the DB size was the stumbling block for Snapshot Replication. We can't do transactional Replication because XL Reporter (one of our reporting tools) needs to write to the DB it is connecting to. I'm not sure that DTS woudl really be any better due to the size of the DB. Thanks for confirming that Log Shipping isn't the right fit for us. Meredith
Post Follow-up to this messageYou can use transactional replication with updating subscribers. As for the initial snapshot, there are ways around that, such as zipping a full backup and restoring, or making smaller publications, each of which is a subset of the original. -- Tom ---------------------------------------------------- Thomas A. Moreau, BSc, PhD, MCSE, MCDBA SQL Server MVP Toronto, ON Canada . "mryan" <coffegrl@gmail.com> wrote in message news:1144097089.313763.220430@e56g2000cwe.googlegroups.com... I believe that the DB size was the stumbling block for Snapshot Replication. We can't do transactional Replication because XL Reporter (one of our reporting tools) needs to write to the DB it is connecting to. I'm not sure that DTS woudl really be any better due to the size of the DB. Thanks for confirming that Log Shipping isn't the right fit for us. Meredith
Post Follow-up to this messagean off the wall question. Would your users like sub one second response times on their most common reports? Woudl they like to to have their data pulled directly into Excel to locate and find exceptions based upon whatever goofy dates, fields, and dreams they have that day? You should SERIOUSLY look into OLAP with that much data, and with that particular application. regards, doug
Post Follow-up to this message
Show a Printable Version
Email This Page to Someone!
Receive updates to this thread