Month: March 2013

Index Selectivity

Here’s a summary of a recent posting on OTN: I have two indexes (REFNO, REFTYPESEQNO) and (REFNO,TMSTAMP,REFTYPESEQNO). When I run the following query the optimizer uses the second index rather than the first index – which is an exact match for the predicates, unless I hint it otherwise: This is actually an example of a […]

Why is my VirtualBox VM not starting properly?

I’ve just wasted quite a bit of time trying to figure out why one of my VirtualBox VMs wasn’t starting properly, so I thought I would share the experience here in case anyone else has a similar issue… It all started because I decided to fire up an OL6 VM, that I hadn’t used for […]

Why is my VirtualBox VM not starting properly? was first posted on March 29, 2013 at 3:46 pm.
©2012 “The ORACLE-BASE Blog“. Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement.

UltraEdit for Linux/Mac v4.0 Release Candidate…

In a previous post I said that UltraEdit moves through beta really quickly. Today I’m rocking UltraEdit v4.0 Release Candidate on Fedora 18… Cheers Tim…

UltraEdit for Linux/Mac v4.0 Release Candidate… was first posted on March 29, 2013 at 11:16 am.
©2012 “The ORACLE-BASE Blog“. Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement.

Missing SQL

From time to time I’ve looked at an AWR report and pointed out to the owner the difference in work load visible in the “SQL ordered by” sections of the report when they compare the summary figure with the sum of the work done by the individual statements. Often the summary will state that the […]

Has Vendor Lock-In Locked Innovation Out?


Make no mistake of it: vendor lock-in is a business goal. Sure, there are some solid benefits in going with one company for your hardware, software, cloud, and all other needs. But doing so can easily mean missing out on best-of-breed options, cost savings, or simple innovation. It is important not to confuse ‘vendor’ with […]

The post Has Vendor Lock-In Locked Innovation Out? appeared first on Steve Karam :: The Oracle Alchemist.

SQL Server 2012: Installing and configuring Distributed Replay

Distributed Replay is a new fonctionality of Microsoft SQL Server 2012. It helps you assess the impact of future upgrades (SQL Server, hardware, OS) or SQL Server tunings by replaying a trace captured from a productive SQL Server environment to a new SQL Server test environment.

This new functionality is similar to SQL Server Profiler, but with more possibilities: e. g. replaying the trace from multiple clients (up to sixteen), use a stress or  synchronization mode, configure options like think time, or connect time etc.


Distributed Replay installation and configurations

To use Distributed Replay, we have to install a Distributed Replay Controller and 1 to 16 Distributed Replay Clients. In this exemple, I will use a Distributed Replay controller and a Distributed Client on server VMTESTSQLWIN01, a second Distributed Replay Client on server VMTESTSQLWIN02 and a target instance with SQL Server 2008 R2 on WMTESTSQLWIN03.

Do not fortget to also install Management Tools which provides Distributed Replay administration tools!


First, we have to create two Active Directory accounts.

1) One for the Distributed Replay Controller: MSTESTDR_controller:


2) And another for the Distributed Replay Client: MSTESTDR_client:



Distributed Replay installation

We now have to install Distributed Replay Controller, Distributed Replay Client, and Management Tools on our VMTESTSQLWIN01 server which will be the Controller of our Distributed Replay and also the Client:


On the Server Configuration, add the two Actice Directory accounts created for Distributed Replay Controller and Distributed Replay Client:


On the Distributed Replay Controller Page, add the Active Directory account previously created for the Controller. On the Distributed Replay Client page, add the Controller name:


Continue the installation until the Complete Screen appears:


Now, our VMTESTSQLWIN01 has Distributed Replay installed.

We have to install the second Distributed Replay Client on VMTESTSQLWIN02:


On the Server Configuration, add the Actice Directory account created for Distributed Replay Client:


Configure the Distributed Replay Controller for the client:


Finish the installation:



Windows Firewall configurations

To allow Distributed Replay Clients to connect and register to the Distributed Replay controller, inbound connection for DReplayClient.exe application has to be allowed on each Distributed Replay Client through the Windows firewall.

Go to Windows firewall, Inbound Rules, and add a new rule for a program:


Browse to the DReplayClient.exe location:


Allow the connection:


Give a name to this new rule and click Finish:


Now, configure the Windows firewall on the Distributed Replay Controller to allow inbound connection for DReplayController.exe application using the same way.

In the target Server VMTESTSQLWIN03, we also have to configure the Windows firewall for inbound on port TCP 1433 to let the Distributed Replay Client write on the target. Select the port:


Protocol TCP and port number 1433:


Allow the connection:


Apply this rule for Domain, Private, and Public:


Specify a name for this new inbound and click Finish to save it:


Now the firewall is configured on each server!


Start Services and check client registrations

You first have to start the Controller service on the Distributed Replay Controller.
Go to VMTESTSQLWIN01, open a command prompt screen and enter:


NET STOP “SQL Server Distributed Replay Controller”
NET START “SQL Server Distributed Replay Controller”


You should see the result of this command in the log folder of Distributed Replay Controller under C:\Program Files (x86)\Microsoft SQL Server\110\Tools\DReplayController\log.

You have now to start Distributed Replay Client service on your Distributed Replay Clients VMTESTSQLWIN01 and VMTESTSQLWIN02. Verify that they are correctly synchronised with your Distributed Replay Controller.

On both servers, open a command prompt screen and run:


NET STOP “SQL Server Distributed Replay Client”
NET START “SQL Server Distributed Replay Client”


To see if the Client is successfully registred with the controller, open the last log file in the location C:\Program Files (x86)\Microsoft SQL Server\110\Tools\DReplayClient\log and check the last line of the file. This could be something like that:


If this was successul for the two clients, the configuration between the controller and clients is finished and the Distributed Replay is ready to work.

If you have a log file like this…


…it means the registration failed, so:

  • check if the controller name is right in the DReplayClient.config file
  • check if, for each client, there is an inbound rule to allow connections for the DReplayClient.exe application
  • check if, for the controller, there is an inbound rule to allow connections for the DReplayController.exe application


At this point, our Distributed Replay application is ready to use, clients and controller are registred together.

You now have to create a trace, preprocess it and replay it from our clients to the target SQL Server.

This will be the content of my next blog posting.

TEL/電話+86 13764045638
QQ 47079569