Featured Article(s)
Troubleshooting Replication subscribers not in sync
Have you encountered a situation where the replication monitor does not show any errors but the users accessing the subscriber table keeps complaining of missing records?
Featured White Paper(s)
How to Achieve 40:1 Backup Compression with LiteSpeed for SQL Server’s SmartDiff
SQL Server can do differential backups, which capture only the parts of the database that have changed since the last full ba… (read more)
Featured Script
sp_MY_sqlmaint_rndx
This procedure will run DBCC DBREINDEX and sp_recompile against all user-defined tables within whatever database it is run in… (read more)
Upcoming Events
SSWUG.ORG Fall Virtual Conference
For the first time there is going to be a room in the Virtual Conference that is live from the start to the end of the conference. If you have questions for the speaker, this is a way you can connect to them right from your desktop.
Join speakers Buck Woody, Donald Farmer, Kevin Kline, Rachel Appel, TJay Belt, Thomas LaRock, Brian Knight and many others at the SSWUG Ultimate Virtual Conference October 21, 22 and 23. Time is running out to register!
SSWUG.ORG Fall Virtual Conference
vWorkshop: SQL Server 911
Are you aware that there are methods of retrieving data, without doing a full database restore? Chris Shaw spends an hour covering such techniques with you during the SQL Server 911 workshop Oct. 15th.
Come see Chris Shaw – Workshop: SQL Server 911 We’ll even be issuing certificates after you successfully complete the course quiz. Hope to see you there!
[Register Here]
Did You Know?
In SQL Server 2005 replication latency or the time it take for a record to make it from the publisher to the subscriber can be measured by a token? This is much easier than older versions of SQL Server that required you to use multiple counters in the performance monitor.
Look for transaction replication and tracer tokens in BOL to get more information.
Database Mirroring Continued
On 9/25 the editorial was about database mirroring, who uses it and when they use it. I received a number of responses that I wanted to share.
Richard: “There’s also the problem of multiple databases. Most of our servers run more than one database, and if we mirror, my understanding is that if the mirrored database fails, it will can force a failover to the mirrored instance (if we’re using a witness) which can break access to the other databases. Thus, your mirror now becomes a single point of failure for all your other databases.”
Recently a discussion I had with someone at Microsoft really opened my eyes to a very similar view point. Database mirroring is more for database redundancy then server redundancy. You can almost look at it as clustering for your database.
Hans: “One thing we recently came to terms with is the maintenance plan issues; as the secondary database is always in recovery mode, no backup can be taken, so we run a script to check the status of all databases, and make sure that the primary databases are all on the same server.” , “The solution has behaved pretty well, but I am not sure about the scalability of it. What if we would configure this for 100 databases?”
A common theme I have heard with database mirroring relates to the same point. It sounds like many DBA’s find when working with a handful of databases that mirroring is great, but more than that looks to be a maintenance concern.
Chris Shaw