Technical Notes - All Comments

re: SQL Server Reporting Services Disaster Recovery Case Study

ccs global tech — Fri, 17 May 2013 10:24:21 GMT

We really appreciate the kind of efforts you have put in this article. There are many ways to perform disaster recovery with Microsoft SQL Server Reporting Services (SSRS. there are few more article about the same issue as these is the up coming issue. for more infomation you can even visit: ccsglobaltech.com/blog.html

re: Reporting Services Scale-Out Deployment Best Practices

Bloti — Fri, 26 Apr 2013 12:57:05 GMT

This article is very informative. It addresses most of the concerns associated with SSRS topology (specifically Scale-Out Deployment. Thanks Gentlemen!

re: Report Server Catalog Best Practices

SQLRumble — Sun, 07 Apr 2013 10:02:13 GMT

Hi, our SEGMENT table in the RSS database (not RSSTempdb) has grown very very big. How can we reduce the size? Can it be truncated or is there a setting somewhere? What kind of information is held in this table. Can I run a query to identify what reports are consuming this table?

re: Eliminating Deadlocks Caused By Foreign Keys with Large Transactions

Sloth — Thu, 04 Apr 2013 23:08:11 GMT

Thank yo so much. I have been wrestling with this issue for months. You've explained this so well!.

re: SQL Server Indexing: Using a Low-Selectivity BIT Column First Can Be the Best Strategy

Susan Van Eyck — Mon, 01 Apr 2013 20:17:21 GMT

Great article - really useful (and interesting) information for an indexing nerd!

re: Resolving scheduler contention for concurrent BULK INSERT

Lonny Niederstadt — Wed, 06 Feb 2013 20:44:24 GMT

Due to the size of the system, and especially the core count per NUMA node, was trace flag 8048 used? I would imagine this would eliminate spinlock contention and cmemthread waits by promoting the NUMA node level resources to core level.

If the scheduler the task is on has other tasks and there are other free schedulers, they must be on another NUMA node. So the point of disconnect and reconnect is to get on another NUMA node where there are idle schedulers.

Wouldn't trace flag 8015 (ignore NUMA and manage as if one big NUMA node) achieve these benefits without the overhead of the disconnects and reconnects?

For a system with multiple batch bulk inserts occurring in batch, there are also other possible benefits to trace flag 8015. Managing a single memory pool can reduce buffer churn in the busiest NUMA node. During ramp up, some of the challenges associated with bad memory sort can be avoided.

It seems that the costs of trace flag 8048 plus trace flag 8015 on such a system would be giving up local memory access(although that's not always much of a benefit on such a system), and the reduction from one lazy writer per NUMA node to one lazy writer.

re: Tuning Backup Compression Part 2

Mbourgon — Fri, 25 Jan 2013 14:15:10 GMT

1) Please note that setting BUFFERCOUNT can cause memory issues, even if only set to 50. " There is insufficient system memory in resource pool 'internal' to run this query."

2) I'm with Mudluck on this - surprised we can't make a compressed backup. And surprised no third-party has done this, either. It went from "we need to do this" to "we can't do this"

re: Scaling Up Reporting Services 2008 vs. Reporting Services 2005: Lessons Learned

Rashid Khan — Tue, 08 Jan 2013 21:10:25 GMT

Excellent article ... Thank you ! -- Rashid Khan

re: Reporting Services Performance Optimizations

Rashid Khan — Thu, 03 Jan 2013 20:19:20 GMT

Excellent article ... very useful indeed.. Thank you ! .... Rashid Khan

re: Reporting Services Scale-Out Deployment Best Practices

Rashid Khan — Mon, 31 Dec 2012 18:05:09 GMT

Excellent article ... very informative indeed... Thank you ! ... Rashid Khan

re: Memory Error Recovery in SQL Server 2012

Stephen — Fri, 21 Dec 2012 17:39:05 GMT

Can Microsoft please comment on Glenn's "Enterprise only" surmising? I'm planning a Win2012/SQL2012 rollout and MUST get the right SQL version...

Thanks for the info and explanations - just this one vital piece of information is missing...

re: Impact of Adding a Node to a Windows Cluster on the Possible Owners property of existing SQL Server Failover Cluster Instances

Sik — Tue, 04 Dec 2012 17:56:06 GMT

Hi Sanjay,

My current cluster set up is like this -

Its a 5 node windows 2008 R2 failover cluster.

Node 1 has a SQL instance 1 set to failover to Node 2. Node 3 has an instance 2 set to falover only node 5.

I think i have exatcly same situation that you have mentioned. But i am not using Always On feature. My instances are all on SQL 2008 R2. Recently we added 2 new nodes to the windows cluster. Now i see that the resource group, ip address in the resource group, Disk drives, SQL Server and SQL Agent in other respurces section shows the possible owners as Node1,Node2,Node3 and Node 5. This is for instance 1. Instance 2 is good as it was installed after we added the new nodes to the windows cluster.

Should i follow the same steps by manually removing the possible owners from instance 1?

re: Reporting Services Scale-Out Deployment Best Practices

fdg — Wed, 07 Nov 2012 00:48:37 GMT

dfgdfg

re: Analysis Services 2005 Aggregation Design Strategy

Niko — Thu, 25 Oct 2012 07:19:17 GMT

Thanks very interested

re: Deploying a Business Intelligence Solution Using SharePoint 2007, SQL Server 2008 Reporting Services, and PerformancePoint Monitoring Server 2007 with Kerberos

Nick I — Wed, 24 Oct 2012 02:26:29 GMT

Probably the best article I've read on how to get this disaster working. Despite going through hundreds of Microsoft documents on implementation, your first problem encountered is what we hit as well. Thanks for this!