patternsqlMinor
Isolating a Distributed Replay environment
Viewed 0 times
distributedisolatingreplayenvironment
Problem
I'm a little nervous replaying a captured trace/workload for performance analysis...
I'm using an isolated service account to run the SQL Services, including the Distributed Replay controller & clients....Is that all that is needed to ensure replayed transactions won't jump across to the prod database?
IE, is it possible that procedures or CLR objects could reach out and connect to another database, even though no linked servers are defined?
TIA!
I'm using an isolated service account to run the SQL Services, including the Distributed Replay controller & clients....Is that all that is needed to ensure replayed transactions won't jump across to the prod database?
IE, is it possible that procedures or CLR objects could reach out and connect to another database, even though no linked servers are defined?
TIA!
Solution
Since the target SQL Server could have a stored procedure using a hard-coded SQL Server account and password to connect to some other server, I'd be unwilling to be 100% certain nothing could touch production unless I had a truly separate network setup to run the Distributed Replay batches against.
One could go to great lengths to try to ensure nothing hits production, but what if you miss something?
I'd setup a bunch of VMs for the controller, replay machines, and the target SQL Server(s), and configure them on their own virtual network, just to be sure.
One could go to great lengths to try to ensure nothing hits production, but what if you miss something?
I'd setup a bunch of VMs for the controller, replay machines, and the target SQL Server(s), and configure them on their own virtual network, just to be sure.
Context
StackExchange Database Administrators Q#132532, answer score: 4
Revisions (0)
No revisions yet.