Now you may want to move the parameterized drillthrough reports on a different folder to implement security and to promote reusability. However when you move the drillthrough reports to seperate folder, the dashboard report breaks and shouts at you since it is not able to locate the drillthrough report in the same folder.

How do you achieve this ?

There are two ways to achieve the above requirements

1. Using to Jump to URL in the Drillthrough Action while designing the reports in BIDS

In this approach, you need to deploy the drillthrough reports first on the report server and get the URL to render the report. You can use this URL in the JUMP to URL option while defining the Drillthrough Actions in the Dashbaord Report.

The only drawback of this approach is, in the dashboard report when the end user clicks on the drillthrough report, the drillthrough report is rendered from here the user can’t go back to the original dashboard report.

2. Creating a Linked Report in the same folder

In this approach, after  we move the drillthrough report in a seperate folder, we need to create a linked report with the same name as the drillthrough report and place it in the same folder as the dashboard.

The Linked report will serve the requirement.

Hope this small tip helps !!!

Parikshit Savjani
Premier Field Engineer

While Log Shipping is pretty easy to configure but configuring log-shipping for a cross-domain clustered instance of SQL server over a Firewall can be trickier which requires some consideration so I plan to discuss these consideration in this blog post for the benefit of larger audience

First Let us discuss Clustering and Log Shipping as HADR Solution

Clustering and Log Shipping
=======================

Until SQL 2012 AlwaysON, we didn’t have a good HADR solution with SQL Server. Clustering serves as a very good High Availability Solution due to minimum failover time as well as SQL Network Name allowing the Application a transparent failover.  However due to the shared storage, Clustering cannot be used as a Disaster recovery solution. While Log Shipping/Database Mirroring serves as a good DR Solution but may not be a good High Availability solution since RPO and RTO depends on the frequency of tlog backup, Network latency.

So Clustering along with Database Mirroring or Log Shipping together serves as a Good HADR Solution where we can take the best of both the worlds

Let us now discuss various considerations in Log Shipping scenario

Considerations for Log Shipping for a Clustered instance
=============================================

For a clustered instance, there is one important consideration. The network share for the Log Shipping should be created as a Fileshare resource on the Cluster.

Further, the fileshare resource should be created in the SQL Group while the shared folder should be created on the shared drive. The dependency of the Fileshare resource should be on Shared Drive in the SQL Group and SQL Network Name.

The reason for creating Fileshare in the SQL Group of the Cluster is so that when the instance is failed over to Node 2, the Log shipping continues to run transparently without any impact. Further the UNC path for the share would be \\<SQL Network Name>\<Folder Name>. This will ensure the copy job will always be able to access the network share on shared drive.

How to create file shares on a cluster
http://support.microsoft.com/kb/224967

Considerations for Log Shipping on a cross domain servers
================================================

While it is possible to establish Log Shipping on a cross domain servers, the only requirement is the two servers should have network connectivity to each other and should be able to access each other.

However the major challenge while establishing Log Shipping on a cross domain servers is permission on the network share which should be accessible to copy job running as under SQL Agent account on the secondary server.

For the SQL Agent account which will be a domain account, to be authenticated by the Primary server, there should be two way trust between the domains.

However if you are not able to establish the two way trust between the domains due to some reason, we can still configure Log Shipping by using Network PassThrough Authentication.

With Network PassThrough Authentication, the SQL Agent account for the servers should have same name and same password.

More information on Network Passthrough Authentication
http://support.microsoft.com/kb/102716

Considerations for Log Shipping over a Firewall
=======================================

While Log shipping uses SMB communication to copy the log files from the Network Share to the local destination folder and hence in order to configure over Firewall, following ports should be open

If,

Netbios over TCP/IP is enabled

TCP ports 137,139
UDP ports 137,138

Direct Hosting of SMB over TCP/IP

TCP port 445

More information on port requirement for Windows Server
http://support.microsoft.com/kb/832017

Further, with Cluster, the above ports should be open in Firewall on Virtual IP address for inbound rules while for outbound rules, it should be open on Physical IP address of the Nodes.

More information for Firewall configuration on Cluster
https://msmvps.com/blogs/clustering/archive/2005/08/11/62372.aspx

While in my case, we had to take all the above consideration to ensure we are a able to setup Log shipping for a clustered instance of SQL Server across cross domain server over a Firewall.

Hope this Helps !!

Parikshit Savjani
Premier Field Engineer

I came across an excellent Blog post from John who has enlisted a comprehensive checklist of the consideration for installing SQL Server setup. Although SQL Server configuration is very easy due to its User Friendly setup and minimal administration. If all the points mentioned in this checklist is taken care off, you can avoid most problems/issues which you might encounter post deployment of SQL Server

http://blogs.msdn.com/b/johnhicks/archive/2008/03/03/sql-server-checklist.aspx

Would like to appreciate the author’s efforts to pen down a comprehensive checklist !!!

Hope this Helps !!

Parikshit Savjani
Premier Field Engineer

If you are migrating to a new server, it is important to capture the IO statistics which is generated by your current workload which can help you to make a decision whether the new server will be able to withstand your current IO workload while providing the expected response time.

In order to capture the current Disk IO statistics, we need to capture the following performance counters

Logical Disk & Physical Disk

Disk Read Bytes/sec   )
Disk Write Bytes/sec  )    Referred as IO bandwidth
Disk Bytes/sec             )
Disk Reads/sec            }
Disk Transfers/sec      }    Equates to IOPs in SAP World
Disk Writes/sec           }
Disk sec/reads             )
Disk sec/Writes           )     Referred as Disk Latency
Disk sec/Transfers      )
Disk Bytes/Read          }
Disk Bytes/Writes       }    IO Transfer Size (generally ranges from 8k to 64k)
Disk Bytes/Transfer   }
Avg Disk Read Queue Length   )
Avg Disk Write Queue Length  )   (Disk Transfers/sec) * (Disk sec/Transfer)
Avg Disk Queue Length             )
If you need more information on these counter, I would recommend you to read this blog.

On my server, I captured the above mentioned performance counters during peak workload and I derived at the following IO statistics generated by current workload.

Ideally the Disk latency is expected to be within 10-15ms so the above counters already suggests the current Disk performance is poor and not meeting the expected standards.

As a result of poor Disk performance, we start seeing IO_COMPLETION, WRITELOG and PAGEIOLATCH_*  wait types in our environment.

Once we have established the IO Statistics for our current workload we can now look at tools available to benchmark our new Storage which will be hosting our SQL Server and will have to provide throughput which exceeds our current workload within the acceptable Disk latency (< 10-15ms).

Our recommended tool for performing SQL IO stress testing is sqlio. There are other third party tools available  viz IOMeter and CrystalDiskMark, however I prefer to use sqlio. it is purely your own comfort and in this blog post I will be talking about sqlio.

We have another tool called SQLIOSim but as per the guidance from Microsoft CSS Blog, It should not be used for  performance testing purpose and should only be used to test the storage from perspective of data integrity and consistency.

Before performing the Stress test, it helps to get the following information from the Storage Vendor

Which RAID configuration is used ?
RAID 10 is recommended for SQL Server.

How many LUNs are configured?
Generally we recommend separate LUNs for datafiles,log files and Tempdb files.

What is strip_unit_size used for LUN ?
It should be multiple of file_allocation_unit_size to address Disk Alignment issues

How much is the Storage Controller Cache available? How much is Read Cache and how much is the write cache?

Larger the Storage Cache, better is the response time at the expense of cost. For SQL Server, it is recommended to have 80/20 or 90/10 ratio of write cache/read cache for SQL Server since large write cache tends to absorb the checkpoint spikes and improves the write performance of SQL Server.

Once we have the above information available, we need to install sqlio.msi which by default installs itself in
C:\Program Files\sqlio                       For 32 bit
C:\Program Files(x86)\sqlio              For 64 bit

More information about SQLIO command line options is already documented by Brent Ozar in his blog post and hence I would not like to duplicate the efforts here.

To start with first we should create a file called testfile.dat in the drive which needs to be stress tested. So we need to make the necessary changes in param.txt to change the drive letter and change the file size as mentioned in the Brent’s blog.

Practically the file size should be around 3 to 4 times the Storage controller cache size. So if the cache size is 5GB we might want to create the testfile.dat of 20GB size. In my case, we create a file of 100GB size.

We can fire the following command to create the file.
sqlio -kW -s10 -fsequential -t8 -o8 -b64 -LS -Fparam.txt timeout /T 10

During this run of SQLIO, ignore the data points and just let the file be created.

The advantage of using SQLIO for IO Stress testing is gives lot of flexibility to generate various IO patterns as generated by SQL Server.

SQL Server generates both random and sequential IO patterns while transfer size of the IO varies from 8k to 64K but doesn’t exceed 64K except for backup and restore operations.

So in our test, we have 3 variable parameters viz

1. IO Pattern (Sequential or Random)  –> 2 values
2. IO Type (Read or Write) –> 2 values
2. IO Transfer Size (8k,64k,128k,256k,512k)  –> 5 values
3. Outstanding IO requests (1,2,4,……1024) –> 11  values

As we all know the rules of testing, if we have 3 variable parameters on which we need to perform the test, we need to vary one parameter at a time while keeping rest of the parameters constant.

So we will have around ( 2*2* 5* 11= 220)  test runs of sql io. I prefer to create bat files for these test runs beforehand and also capture the above mentioned perfmon counters while running the tests.

Random Read Test

sqlio -dE -BH -kR -frandom -t1 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t2 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o2 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o4 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o8 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o12 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o16 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o64 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o128 -s120 -b64 -LS testfile.dat

Note: Do not exceed the no. of threads (-t) beyond the number of processors on the server.

In this test run, as mentioned earlier we keep other parameters constant while varying only 1 of the parameter. So we have random read and io transfer size is fixed to 64KB while outstanding io ( no. of threads (-t) * no. of io per threads (-o)) is increased in steps from 1 to 512.

For the above test, I created a bat files and routed the results to text file. In the output, we need to capture MBs/sec, IOs/sec and Avg_Latency(ms) for each test runs.

We captured the result in the excel sheet as shown below

Based on the above results we plotted 3 graphs as shown below

So we see that as the outstanding IOs increases the IOPs and IO MB/sec (in other words Disk throughput) also increases until 32 outstanding IOs, beyond which there is no increase in Disk throughput even when there is increase in outstanding IOs.

Any guesses why the graph saturates at 32 outstanding IOs?
No marks for guessing that 32 is HBA queue depth setting which can further increased to 256 if required. For SQL Server generally, the HBA queue depth between 32 and 64 is recommended so you might want to increase the queue depth setting if Disk throughput at 32 outstanding ios doesn’t meet the current workload requirement.

However from SQL Server perspective, the most important parameter which you are interested is the Disk Response time which should be within 15 ms. As seen in the graph, the until 48 outstanding IO requests, the Disk responds under the acceptable limits beyond which it begin to increase exponentially.

Large Random Read Test

In this test, we keep the outstanding IO request constant to 32 (as found from the above test) generating random reads of various IO sizes varying from 8K to 512K.

sqlio -dE -BH -kR -frandom -t4 -o8 -s120 -b8 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o8 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o8 -s120 -b128 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o8 -s120 -b256 -LS testfile.dat
sqlio -dE -BH -kR -frandom -t4 -o8 -s120 -b512 -LS testfile.dat

Following are the results from our testing

In this test, between 8k to 64KB if we get the acceptable response time and our IOPs requirement meets the our current workload requirement,  Disk is said to meet the test requirements.

Similarly,

We need to perform the following test
Random Write Test

sqlio -dE -BH -kW -frandom -t1 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t2 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o2 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o4 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o8 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o12 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o16 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o32 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o64 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o128 -s120 -b64 -LS testfile.dat

Large Random Write Test

sqlio -dE -BH -kW -frandom -t4 -o8 -s120 -b8 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o8 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o8 -s120 -b128 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o8 -s120 -b256 -LS testfile.dat
sqlio -dE -BH -kW -frandom -t4 -o8 -s120 -b512 -LS testfile.dat

Sequential Read Test

sqlio -dE -BH -kR -fsequential -t1 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t2 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o2 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o4 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o8 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o12 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o16 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o64 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o128 -s120 -b64 -LS testfile.dat

Large Sequential Read Test

sqlio -dE -BH -kR -fsequential -t4 -o8 -s120 -b8 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o8 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o8 -s120 -b128 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o8 -s120 -b256 -LS testfile.dat
sqlio -dE -BH -kR -fsequential -t4 -o8 -s120 -b512 -LS testfile.dat

Sequential Write Test

sqlio -dE -BH -kW -fsequential -t1 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t2 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o1 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o2 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o4 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o8 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o12 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o16 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o32 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o64 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o128 -s120 -b64 -LS testfile.dat

Large Sequential Write Test

sqlio -dE -BH -kW -fsequential -t4 -o8 -s120 -b8 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o8 -s120 -b64 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o8 -s120 -b128 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o8 -s120 -b256 -LS testfile.dat
sqlio -dE -BH -kW -fsequential -t4 -o8 -s120 -b512 -LS testfile.dat

The results can be captured and verifies whether it meets the expected workload requirement within the acceptable response time (< 15ms).

Hope this Helps !!

Parikshit Savjani
Premier Field Engineer

Disclaimer: This post is provided “AS IS” with no warranties, and confers no rights

The focus of SQL 2012 has always been to provide a reliable,robust and Highly Available Database Solution to give the customer enough confidence to host their Tier 1 data on SQL Server.

AlwaysON and Indirect Checkpoints are some of the new changes in SQL 2012 which gives you an assurance of High Availability with minimum downtime.

I wouldn’t say indirect Checkpoints as a new feature of SQL 2012 since it is just a change in the algorithm but a very important change as well since it overcomes the flaws of the previous algorithm.

Checkpoints are mainly used to minimize the recovery time interval. At Checkpoints all the dirty buffers are flushed to disk so after the checkpoint is finished we are sure that datafile is consistent and contains all the committed transactions which occurred before checkpoint.

The Recovery Time Objective (RTO) for a given database decides the frequency of the checkpoints.

In SQL Server, we have configuration parameter viz recovery_interval(min) which is used to set your recovery time objective. By default recovery_interval is set to 0 which sets the RTO to 1 min, so SQL Server will internally calculate the frequency of the checkpoints so that recovery should not take more than 1 min to bring the database online.

Let us understand the current checkpoint algorithm and its challenges

Current Checkpoint Algorithm

• In our current checkpoint algorithm, based on the recovery interval(min), SQL Server internally calculates the regular intervals in the Tlog at which the checkpoint happens. In other words, checkpoint frequency is dependent on the no. of transactions in the Transaction log.
• However a given transaction can insert/update/delete multiple dirty buffers.
• So let us say after a Checkpoint we have some transactions which are inserting/updating/deleting large number of dirty buffer and if the crash happens after that, all these dirty buffers needs to be recovered by SQL Server.
• The recovery time is mainly dependent on the number of dirty buffers to recover.
• However our current checkpoint algorithm doesn’t account for the number of dirty buffer to be recovered.
• Hence Recovery Interval(min) cannot be predicted our guaranteed.
• Further, the flushing of dirty buffers occurs only at checkpoints and doesn’t occur anywhere in between which results in IO spikes at the time of checkpoint.

Challenges of Current Checkpoint Algorithm

Indirect Checkpoint Algorithm

In the new Indirect Checkpoint Algorithm

• We need to first set target_recovery_time which is a new database level setting.
• Once the target_recovery_time is set, SQL Server internally calculates target dirty buffer threshold.
• As the transaction are logged in the Tlog, the LSN and dirty buffers which are modified by the transaction are tracked in Dirty Page List. So in the indirect checkpoint algorithm, we now track the dirty buffers from each transaction alongwith their LSN.
• A new Background process, called Recovery Writer is introduced starting SQL 2012. The job of the recovery writer is to periodically POLL the Dirty Page List to see the following

IF ( No. of Dirty Pages in BPOOL > Target Dirty Buffer Threshold)
{
Flush Dirty Buffers
Move MinRecoveryLSN to the next transaction until which the dirty buffers are     flushed
}

• Recovery Writer is a new background thread which wakes up periodically based on a timed event to poll the dirty page list
• DIRTY_PAGE_POLL is a new system waittype introduced to support timed wait of RECOVERY WRITER thread and if you see it as one of the high wait events in sys.dm_os_wait_stats you can safely ignore it.
• With the new recovery writer thread, SQL 2012 ensures at any given point in time there is not more than target dirty buffers in the Buffer Pool, which can easily recovered within target recovery time.
• The Checkpoint Background process is now not responsible for flushing the pages but instead is used to calculate the MinRecoveryLSN

You can view the new recovery writer thread in the SQL Instance using the following query

<span class="kwrd">select</span> * <span class="kwrd">from</span> sysprocesses <span class="kwrd">where</span> spid=2

With the new indirect Checkpoint algorithm ,

• Target Recovery Time can be guaranteed and is predictable since the dirty page list is tracked by SQL Server.
• IO spikes  occurring at Checkpoints are now smoothen out since the checkpoint process doesn’t flush dirty buffers but the Average IO Workload of the SQL Server will increase.
• Setting the Target Recovery Time too small, can cause background recovery writer to run aggressively and thereby increases the IO workload for large OLTP systems.

POINTS TO REMEMBER

CALL TO ACTION

Parikshit Savjani
Premier Field Engineer

Disclaimer: This post is provided “AS IS” with no warranties, and confers no rights

Note: This is my interpretation of the Checkpoint Algorithm. This blog should not be treated as official document or record exposed by Microsoft.

The following script should help to achieve the objective so sharing with the larger audience

SET NOCOUNT ON DECLARE @Tbl Table ( dbname varchar(30), file_id int, filename varchar(30), physicalname varchar(100), TotalSize int, Freespace int, PctFreespace int ) insert into @Tbl EXEC sp_MSforeachdb ‘SELECT db_name(),[file_id],name,physical_name,size/128.0, size/128.0 – CAST(FILEPROPERTY(name, ‘‘SpaceUsed’‘) AS int)/128.0, (size/128.0 – CAST(FILEPROPERTY(name, ‘‘SpaceUsed’

<span class="str"><span style="font-size: x-small;">') AS int)/128.0)</span></span>

*100/(size/128.0) FROM sys.database_files’ IF EXISTS(select * from @Tbl where PctFreeSpace <= 40) BEGIN –<<Send Alert>> select * from @Tbl where PctFreeSpace <= 40 END

Hope this helps !!!

Parikshit Savjani
Premier Field Engineer

Hope you find them useful

Does Parallel Plan for rebuild index impact the fragmentation of index?

http://sqlservergeeks.com/blogs/Parikshit/personal/427/does-parallel-plan-for-rebuild-index-impact-the-fragmentation-of-index

Understanding SQL Server Page Allocation using new sys.dm_db_database_page_allocations introduced in SQL 2012

http://sqlservergeeks.com/blogs/Parikshit/personal/433/understanding-sql-server-page-allocation-using-new-sys-dm_db_database_page_allocations-introduced-in-sql-2012

Parikshit Savjani
Premier Field Engineer

However, in my first encounter with AlwaysON, I was hit with the following error while joining the secondary replica to the Availability Group

TITLE: Microsoft SQL Server Management Studio
————————————————————-

Failed to join the instance ‘DSI-CLUNODE2′ to the availability group ‘AVG’. (Microsoft.SqlServer.Management.SDK.TaskForms)

——————————
ADDITIONAL INFORMATION:

An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)

——————————

Failed to join local availability replica to availability group ‘AVG’.  The operation encountered SQL Server error 41106 and has been rolled back.  Check the SQL Server error log for more details.  When the cause of the error has been resolved, retry the ALTER AVAILABILITY GROUP JOIN command. (Microsoft SQL Server, Error: 41158)

When I checked the Errorlog, I see my errorlog filled with following error messages

Error: 18456, Severity: 14, State: 5.
Login failed for user ‘DOM2K8R2CLUDSI-CLUNODE2$’. Reason: Could not find a login matching the name provided.

The error message tells me login failure error messages for the machine account (DOM2K8R2CLUDSI-CLUNODE2$) of Node 2 on the SQL Instance on Node 1.

So I consulted my senior colleague and I got following reply from Suresh Kandoth ,Escalation Engineer with Microsoft CSS Team

If we are using virtual accounts (Service SIDs in my case) for service startup of db engine, then if that service goes outside the machine, authentication on the remote system will be performed using machine account. So on the target server [SRV1] we need to add the windows login [domain_nameSRV2$] and give appropriate permissions.

Now, I understand that machine account of Node 2 is required to be a login to Node 1 and the same login should have connect permissions to database mirroring endpoint created by AlwaysON Group as documented ( Thanks to my colleague Jwalanth Chavan in Microsoft for providing the link ) in the following

MSDN link:  http://msdn.microsoft.com/en-us/library/ms366346(v=SQL.110).aspx

For two server instances to connect to each other’s database mirroring endpoint point, the login account of each instance requires access to the other instance. Also, each login account requires connect permission to the database mirroring endpoint of the other instance.

The impact of this requirement depends on whether the server instances run as the same domain user account:

· If the server instances run as the same domain user account, the correct user logins exist automatically in both master databases. This simplifies the security configuration the database and is recommended.

· If the server instances run as different user accounts, user logins on the server instance that hosts the principal server or primary replica must be manually reproduced on the server instance that hosts the mirror server or on every server instance that hosts a secondary replica. For more information, see Create a Login for a Different Account and Grant Connect Permission, later in this topic.

So to resolve the issue, I created a login for machine account (DOM2K8R2CLUDSI-CLUNODE2$) of the secondary replica on the primary instance and granted it connect permission to the database mirroring (hadr_endpoint) endpoint and vice versa.

ON Primary Replica

use [master]
GO
CREATE LOGIN [DOM2K8R2CLUDSI-CLUNODE2$] FROM WINDOWS
GO
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DOM2K8R2CLUDSI-CLUNODE2$]
GO

ON Secondary Replica

use [master]
GO
CREATE LOGIN [DOM2K8R2CLUDSI-CLUNODE1$] FROM WINDOWS
GO
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DOM2K8R2CLUDSI-CLUNODE1$]
GO

The above error was resolved and my secondary replica now looks clean without any errors as shown below

To conclude,

If the service startup account of the instances participating in AlwaysON are domain accounts, the AlwaysON GUI  creates the logins for the startup account and grants it connect permissions to hadr_endpoint on the opposite instances.

However in case when  the service startup account of the instances participating  AlwaysON is Service SIDs, the AlwaysON GUI doesn’t create login for the machine accounts on the opposite instances and hence we see the above error. As confirmed by the product team, it is by design behaviour and  recommendation is to manually

1. Add the logins for machine accounts (in other instances) and
2. Give the connect permission to hadr_endpoint.

However, I am yet to confirm whether running SQL Server instance on Service SIDs is supported for AlwaysON scenario.

Special thanks to Jwalanth Chavan,Suresh Kandoth and Balmukund Lakhani to help me identify the cause of the issue.

The same issue is also discussed in the thread

http://social.msdn.microsoft.com/Forums/en-US/sqlhadr/thread/616b9f77-fbd4-49fa-9887-b84ca72544a5

Hope this helps !!!

Parikshit Savjani
Premier Field Engineer

To deal with such situation Reporting Services doesn’t have an Out of Box solution, so in this Blog I would like to discuss on how I managed to achieve to this

Method 1: (Preferred Method for Enterprise Edition of SQL Server)

Use Data Driven Subscriptions

If you are using Data Driven Subscriptions, you can prevent the Subscriptions being fired by modifying the query used for Data Driven Subscriptions as

select * from <<Data driven subscription table>>
where exists ( select top 1  << query which populates the dataset in report and select only one column in the query>>)

Make sure to use top 1 in query to fetch only 1 row and select only 1 column in the column list in the query since the intention is only to check the existence of data from the query

Method 2: (Preferred Method for Other Editions Of SQL Server)

Use Custom T-SQL Script to trigger the subscription Job

The reason I list this method as preferred method for other editions is since Data driven subscriptions is available only with Enterprise Edition of SQL Server and hence for all editions we will have to use this method.

As we know, each subscription creates a Job in SQL Agent which has named on GUID generated internally. At the defined schedule, the sql agent job kicks in to run the report and sends the report to the defined subscribers.

We use the same concept, however in our case we first need to check the existence of the data in the report and if data exist we can invoke the job.

We cannot afford to modify the existing job since it will land us in unsupported scenario.

So we first modify the schedule of subscriptions to run “once” on a schedule date of the past (may be yesterday). You can do this using Report Manager where you go the subscriptions tab for the report and edit the schedule. We do this so that report subscription remains active and enabled but at the same time doesn’t invoke the Job since we will invoke the job programmatically using our scripts.

We now create a new T-SQL job and add the following script. We schedule this job to run on the same schedule as the original subscription was initially configured

IF EXISTS
(
<<SELECT TOP 1 query to check data existence>>
)
BEGIN
DECLARE @Jobid uniqueidentifier
DECLARE @Subscriptions TABLE
(Jobid uniqueidentifier)

INSERT INTO @Subscriptions
select sch.ScheduleID from Schedule sch
INNER JOIN Subscriptions subs ON sch.[EventData]=subs.SubscriptionID
INNER JOIN Catalog cat ON subs.Report_OID=cat.ItemID
where cat.Name=<<Report Name>>

select TOP 1 @Jobid =Jobid from @Subscriptions
WHILE(@@ROWCOUNT<>0)
BEGIN
EXEC msdb.dbo.sp_start_job @Jobid
DELETE FROM @Subscriptions where Jobid=@Jobid
select TOP 1 @Jobid =Jobid from @Subscriptions
END
END

So the new job created will run on the defined schedule, it will check for the existence of the data in the report and if data exists, it will invoke the subscriptions job which will run the report and send the report to subscribers.

Hope this helps !!!!

Parikshit Savjani
Premier Field Engineer

param($sqlserver)
[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SqlServer.Smo”) | Out-Null
$srv = New-Object “Microsoft.SqlServer.Management.Smo.Server” $sqlserver
$srv.JobServer.Jobs | foreach {$_.Script()}

You can copy the above code in a notepad and save it as .ps1 file in some location on server.

Next from the Object Explorer in SQL Management Studio, right click the SQL Server Name and Click on Start Powershell as shown below

This will open up powershell prompt. In the Powershell prompt you can run the above code as below

<exact path of file>scriptjobs.ps1 <<Instance Name to script>>   >     <<path of the file to redirect the script output>>

For e.g.

PS SQLSERVER:SQLPARIKS-MSFTDEFAULT> C:UserspariksDesktopscriptjobs.ps1 PARIKS-MSFTSQLR2 > C:UserspariksDesktopJob.sql

The Job.sql file will be created which will have all the Jobs scripted for that instance.

Parikshit Savjani
Premier Field Engineer