|
Home > Archive > MS SQL Server > April 2006 > Looking for a suggestion
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Looking for a suggestion
|
|
|
| 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
| |
| Tom Moreau 2006-04-03, 8:23 pm |
| Log 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
| |
|
| 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
| |
| Tom Moreau 2006-04-03, 8:23 pm |
| You 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
| |
|
| an 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
|
|
|
|
|