Featured Article(s)
Elemental MDX: Members, and an Introduction to Member Functions, Pt. 1
Part 1: BI Architect Bill Pearson continues his Elemental MDX Series with an introduction to the ”members” concept in MDX, before exploring the .Members function. Next, he introduces member “family” functions, beginning the exploration of this general group of MDX functions with the .Parent, .Children and Ancestor() functions.
Webcast: SQL Server Forensics
Have you ever received a call from one of your users asking why they received an error 3 days ago? Or maybe they want to know when a particular piece of data was deleted and who did it. Troubleshooting past events is difficult in SQL Server, but not always impossible. Learn how to set up a SQL Server to be able to respond these questions and how to use resources within SQL Server and other application logs to track down activity that otherwise might be lost.
Presented by: Sarah Barela
> Register Now
> Live date: 4/14/2010 at 12:00 Pacific
Consolidation, Virtualization Success Keys
I was going to write about "well, it seems that virtualization success relies on…" type stuff. It occurred to me though that there is some very common ground here between virtualization, consolidation and simply bringing up your SQL Servers. The key is in understanding load and being smart about how you build out your solutions.
The virtualization successes that people wrote in about were with systems where the application loading was well know for all of the applications on the server. The disk arrays were well configured, the load on the box was known and thought through and the IO systems were well-known in terms of their load, utilization and configurations. Sounds pretty obvious when you think about it. Trying to think through how to present this, it’s clear that it’s very similar to what you need to know about when it comes to server consolidation and general configuration.
You need to know what your systems are capable of (speed, utilization, etc.) and what your applications on that server will demand. This means ALL applications, be they in a different virtual machine or simply running as an application on the box. One thing to keep in mind as you map this out for a given server is that you need to think about how your servers are used. You may be able to fit applications together a bit like puzzle pieces, depending on your patterns of usage. For example, if you have an application that is heavy AM usage and one that is lighter in the AM, but heavier in the afternoon, you may (may!) be able to allow them to co-habitate on a server. It’s not ideal – things may grow – but it’s possible as things are when you’re reviewing your systems.
As we all do more with our servers, I think it’s going to be critical to success with the systems to know the loading, know the capacity and understand the usage spikes, performance bottlenecks and how to fit the pieces together. For every issue submitted about virtualization, there were long emails about the successes of virtualization. These successes were *all* based on a simple fact, that the systems were able to handle the loading and that the applications fit that loading accurately. This is very important though… it’s not limited to virtualization, it’s more about matching your server to all of the applications running on it. Before you say "duh!" consider carefully how things have changed.
So many shops now are pulling applications together and putting them on common physical boxes. Many times only the biggest or more notable application is well-known on the box. There may be all sorts of other things on the system. Take time to re-inventory your applications and understand fully what’s on the box and you’ll have a far greater chance of matching the server with the application and having success in the consolidation/virtualization/configuration of the box.
Webcast: Basics of Administering Databases for The Layman – Part 3
Okay, so you’ve gotten your data into your database. Did you do it right? Do you have too much data? Do you have the right data? Can you actually get the data out that you want? Now how do you get it out? This session will take you through some examples of why you want to have less data in a database to be more accurate (normalization), how that’s done, and how it makes the data in your database more accurate. It also explains why, in certain circumstances, it could be beneficial not to do that. Topics included will be indexes: what, why, and how to use them, what the benefits are, what the tradeoffs are. Also, different ways to maintain them and why you want to do that, and why some of Microsoft’s canned maintenance plans can be a problem and where to look for solutions to those problems.
Presented by: Tom Roush
> Register Now
> Live date: 4/21/2010 at 12:00 Pacific