Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Development and Production Database Expand / Collapse
Author
Message
Posted Friday, December 5, 2008 9:13 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, February 18, 2009 12:25 PM
Points: 9, Visits: 25
I think in the long run you might be best off by creating simulators - small apps or scripts that produce transactions similar to production. Over time you could evolve these into a full test suite that could simulate all of the possible types of transactions.

Post #614655
Posted Friday, December 5, 2008 10:42 AM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Wednesday, October 8, 2014 9:35 AM
Points: 2,223, Visits: 3,649
writing triggers on all tables would be little cumbersome and as said earlier would hit production.

You can also think of implementing log shipping. keep log backup interval relatively higher and use this interval to study the data in ur developement database by bringing database in multi_user mode.. Hope u're not planning to enter data into developement simultaneously..






Pradeep Singh
Post #614782
Posted Saturday, December 6, 2008 5:18 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 10:14 AM
Points: 35,371, Visits: 31,915
Periodic "Log Shipping" or on demand "Replication" would do it.

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #615200
Posted Monday, December 8, 2008 6:41 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, October 17, 2014 3:41 AM
Points: 210, Visits: 116
Jeff you beat me to it. I would most certainly look at using Transactional Replication to solve this issue, assuming that's going to be suitable for your environment.

However the idea of capturing trace information is something I hadn't considered before and offers up some nice functionality such as repeatable tests which could be easily added into a dbfit FitNesse test for example.



Post #615506
Posted Thursday, May 27, 2010 8:27 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, August 9, 2011 12:00 PM
Points: 3, Visits: 48
What we're doing is simple as long as you script your database changes from DEV to PROD. Here how it goes.

1) We backup PROD database every day (week or month. Depends on your dev cycle)
2) We restore PROD database into another database and run clean-up scripts (due to compliance on sensitive data)
3) We backup cleansed database and port backup file(s) to DEV environment
4) We restore cleansed PROD backup on DEV environment and run incremental script to bring PROD "data" to DEV schema.
Post #929021
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse