Hi,
In my db I have a big table with at least 40 millions rows.
In fact my appz soffer about performance and I had to put
offline the oldest data.
I keep online only the last 6 monthsm and I copy the oldest in
some tables with data costraints...
I mean I have a table called "TbPrices" and then I have
TbPrices_2003_12,
TbPrices_2003_11
and so on.
I think to use a replication db to have the entire archive with a clustered
view and
the OLTP with the last 10 days online.
But I don't know how replication works because I don't want to delete the
record in
the destination.
Thanks
You can use replication for this but you have to be careful.
I am confused by what you mean by a clustered view? Do you mean an indexed
view, or perhaps a distributed partitioned view?
Replication can be used to replicate a subset of data to an archive table,
ie only replicate data older than 6 months perhaps.
You should use a date filter to only replicate data which is less than 6
months old. Then when you are creating your publication ensure that you use
the 'delete all data which matches the row filter clause' you can find in
the specify articles dialog of the create publication wizard. Click the
three ellipses to the right of your article name, and select the snapshot
tab. In the name conflicts section select this option.
This will ensure when you reinitialize the archived data on your subscriber
is not wiped out.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"opianeta" <opianetaNONMISPAMMAREPLEASE@.yahoo.it> wrote in message
news:7R0Xc.458$v24.9883@.news.it.colt.net...
> Hi,
> In my db I have a big table with at least 40 millions rows.
> In fact my appz soffer about performance and I had to put
> offline the oldest data.
> I keep online only the last 6 monthsm and I copy the oldest in
> some tables with data costraints...
> I mean I have a table called "TbPrices" and then I have
> TbPrices_2003_12,
> TbPrices_2003_11
> and so on.
> I think to use a replication db to have the entire archive with a
clustered
> view and
> the OLTP with the last 10 days online.
> But I don't know how replication works because I don't want to delete the
> record in
> the destination.
> Thanks
>
Showing posts with label fact. Show all posts
Showing posts with label fact. Show all posts
Friday, March 23, 2012
Replication can solve may problem ?
Monday, March 12, 2012
Replication and FK Constraint
Let me preface this w/ the fact that I may be stupid...
In trying to test replication in SQL 7 I created a staging database to hold one table (tblStaff) that I would try to replicate into the "live" version of tblStaff in another DB (on the same server).
The "live" version of tblStaff obviously (perhaps) has a number of dependent tables (and stored procedures - which are really only select queries) that rely on the StaffID key. I have turned off the "Enable key for replication" in all the dependent tables and, for good measure, in tblStaff. I then created a publication of the stagingDB tblStaff and a pull subscription on the live DB. But...(snapshot) replication *still* fails w/ an error that dropping the live tblStaff would violate foreign key constraints.
Thanks in advance.What was the error?|||"Could not drop/truncate (depending on the option chosen earlier in the process - tried it both ways) table due to foreign key constraint."
As an (inelegant) workaround I wrote two scripts to drop and add the constraints and then synch. in the middle. It works and the table only has to be replicated every now and again but... I would still like to know the "real" way to do it.|||Use the NOT FOR REPLICATION Option and refer to BOL for more information.|||I already did that.|||May check this Article (http://www.windowsitlibrary.com/Content/77/11/1.html) about do's and dont's.
In trying to test replication in SQL 7 I created a staging database to hold one table (tblStaff) that I would try to replicate into the "live" version of tblStaff in another DB (on the same server).
The "live" version of tblStaff obviously (perhaps) has a number of dependent tables (and stored procedures - which are really only select queries) that rely on the StaffID key. I have turned off the "Enable key for replication" in all the dependent tables and, for good measure, in tblStaff. I then created a publication of the stagingDB tblStaff and a pull subscription on the live DB. But...(snapshot) replication *still* fails w/ an error that dropping the live tblStaff would violate foreign key constraints.
Thanks in advance.What was the error?|||"Could not drop/truncate (depending on the option chosen earlier in the process - tried it both ways) table due to foreign key constraint."
As an (inelegant) workaround I wrote two scripts to drop and add the constraints and then synch. in the middle. It works and the table only has to be replicated every now and again but... I would still like to know the "real" way to do it.|||Use the NOT FOR REPLICATION Option and refer to BOL for more information.|||I already did that.|||May check this Article (http://www.windowsitlibrary.com/Content/77/11/1.html) about do's and dont's.
Subscribe to:
Posts (Atom)