DBA School Registration is Open
Limited seats remain… [Get More Information]
Featured Article(s)
Troubleshooting SQL Server 2005 Joins (Part 1)
In this article, Alexander Chigrik explains some problems that you can have when you work with SQL Server 2005 joins. He also tells how to resolve these problems.
Webcast today – Register now to attend/view
DTS Conversion to SSIS * Conversion Best Practices
Join this webcast and Learn how and why to convert DTS to SSIS. See how you can save time and money and easily migrate your DTS packages to SSIS * Introduction to SSIS and its differences vs. DTS * Advantages of SSIS over DTS * Options for converting DTS packages to native SSIS * Adding value to packages during the conversion process * Assessing the scope of a DTS conversion project. Presented by: Brian Knight
> Register Now
> 8/5/2009 at 12:00pm Noon Pacific
Determining Root Cause with SQL Server Issues
How many times have you arrived in the morning to find there was a performance issue overnight? The middle of the night problems are almost impossible to troubleshoot if no one is there to see it happening, or the root cause is something intermittent. Now there is a solution for this – Idera’s SQL Diagnostic Manager has a "History browser" feature which lets you view the performance and activity on a server as they were in the past. This is an indispensable tool for troubleshooting and fixing SQL Server issues, especially those that occur intermittently or off-hours. You can give it a try by downloading a free trial of SQL diagnostic manager.
Initial Feedback on Mixed Schemas with SQL Server
Some great feedback on the concept or idea of splitting schemas for your databases so they support both the transaction side of your business and the reporting side of your business.
While I’ve had a bunch of emails on this, they net out to two different distinct schools of thought:
1. Yes! Break them apart and then make the denormalized information available to your reporting users. The pros of this are that they can optimize the transaction and reporting views of the databases independently. This helps both "sides" and provides some real-world benefit. A few people mentioned too that this meant having the ability to shake out security on the reporting side of things in ways that are different from the transaction side of the house. Interesting benefit that I really hadn’t considered.
2. No! The biggest reason against breaking the schemas apart was simply the management and maintenance of two potentially very different data stores. The art of managing these two, sharing information reliably between them and still providing that most-revered "single source of the truth" proved to be very tough indeed if the schemas don’t match, let alone in two different databases. The resolution? It’s two-fold in this case. First, break stuff apart so you have a transaction database and a reporting database, maintained by something akin to replication or log shipping, etc. Second, tell reporting users that it just may take a bit of time to generate the reports. Simple fact of pulling at that information together to answer their queries.
Good points on both sides, but I think I’d opt for the initial pain of #1.
What do you think? Drop me an email with your approach here.
Featured White Paper(s)
Java Database Connectivity
Database connections are the lifeblood of enterprise applications, administrating the secure and steady flow of information b… (read more)