Wednesday, March 21, 2012

Move test data to production SQL Server

Hi All,
Could someone point me to a white paper/best practices on how to move/update
data from test sql server to a production sql server?
Both of the server have the same schema.
I would like to know if there is a way to synchronize the two databases.
Would SQL Server Replication be a good idea?
Many thanks,See http://www.red-gate.com for the SQL Data Compare product. We use Red
Gate's SQL Compare and SQL Data Compare (mostly in development, testing, and
production prep -- not transitioning to production). SQL Data Compare
quickly compares and allows you to synchronize two databases.
A more robust solution that accounts for "production data" being preserved
while merging in updated lookup tables, et. al., simply requires analyzing
your needs (which takes _time_) and then, in our case, maintaining a central
script for the lookup tables (which also takes _time_). Our script is
simply a 1) disable constraints 2) delete, repopulate lookup tables, 3)
re-enable constraints (and run DBCC CHECKCONSTRAINTS to make sure nothing
unexpected happened!)
"Amine" <Amine@.discussions.microsoft.com> wrote in message
news:D92C4BF2-4EE9-4B64-BA32-D39D4BC21D15@.microsoft.com...
> Hi All,
> Could someone point me to a white paper/best practices on how to
move/update
> data from test sql server to a production sql server?
> Both of the server have the same schema.
> I would like to know if there is a way to synchronize the two databases.
> Would SQL Server Replication be a good idea?
> Many thanks,
>
>|||Mike:
What do you mean by lookup tables?
"Mike Jansen" wrote:

> See http://www.red-gate.com for the SQL Data Compare product. We use Red
> Gate's SQL Compare and SQL Data Compare (mostly in development, testing, a
nd
> production prep -- not transitioning to production). SQL Data Compare
> quickly compares and allows you to synchronize two databases.
> A more robust solution that accounts for "production data" being preserved
> while merging in updated lookup tables, et. al., simply requires analyzing
> your needs (which takes _time_) and then, in our case, maintaining a centr
al
> script for the lookup tables (which also takes _time_). Our script is
> simply a 1) disable constraints 2) delete, repopulate lookup tables, 3)
> re-enable constraints (and run DBCC CHECKCONSTRAINTS to make sure nothing
> unexpected happened!)
> "Amine" <Amine@.discussions.microsoft.com> wrote in message
> news:D92C4BF2-4EE9-4B64-BA32-D39D4BC21D15@.microsoft.com...
> move/update
>
>|||By lookup tables I simply meant tables that are read-only, that the
application doesn't update.
I've got to run, but if you need more info on what I mean, let me know and
I'll try to be more detailed.
"Amine" <Amine@.discussions.microsoft.com> wrote in message
news:6C29CC4B-9B2C-4930-8269-2D3B371D28B9@.microsoft.com...[vbcol=seagreen]
> Mike:
> What do you mean by lookup tables?
>
> "Mike Jansen" wrote:
>
Red[vbcol=seagreen]
and[vbcol=seagreen]
preserved[vbcol=seagreen]
analyzing[vbcol=seagreen]
central[vbcol=seagreen]
nothing[vbcol=seagreen]
databases.[vbcol=seagreen]

No comments:

Post a Comment