Your History in the Making?Many, many years back, Microsoft was working to introduce a new toolset for Windows developers - it was code-named "Thunder" and was the start of Visual Basic. At the time, Borland was just starting to get into the Windows arena, and Windows 3.x was just a "cool" tool for DOS.
At the time, "interrupt-driven" programming, the Windows API and such were just things programmers were using because they were new and exciting. The feuds were beginning between DOS-based applications (fast) and Windows-based applications (slow, but the UI could be built more cleanly). Few really knew at the time that Windows was "it" and that Visual Basic, and the other tools built for Windows would be the standard, and DOS applications were really just a stepping stone to getting to the next level.
That's really were we are today with SQL Server. I spent some time with several OLAP vendors - many teaching, preaching or generally showing off their wares in the OLAP space. You've seen a lot of press about OLAP - just like developers used to with Visual Basic's introduction. OLAP is out there, but in my experiences, and according to those vendors at the conference, DBA's still aren't getting the idea in general, and most are simply looking at it as a new tool.
I would suggest strongly that if you're one of these, you reconsider.
You've been reading about it for months, and you've seen it in the press quite a lot. OLAP is here to stay. Think about it - all of the information sources are converging - this is great until you think that what this really means is a glut of information like we've all never experienced before. HUGE databases are soon to be the norm, vast amounts of information truly at our fingertips. It comes from our new data-driven web sites, from our online e-commerce solutions, from the contact management and sales systems and more. All of this information leads to more and more questions, more and more demand for meaningful use of the information.
That's truly the promise of OLAP of course. But you knew that. The thing that really has to be explored is why, how and what happens to the information when we delve into this new information mining age. Like the early days of the Visual Basic developer tools - OLAP is cool, the next thing, etc. But the fact is, as DBAs, we simply must step up to the plate in working with OLAP.
For example, the applications that run against an OLAP-aware server - how do they run with 100's or even 1000's of queries hitting a Very Large Database? What if that database is also shared with other applications? How do you separate an OLAP database from those other applications as it begins to impact overall performance? These issues are not new (you've certainly learned by now that serious database usage requires a database server that's dedicated, etc.) but with OLAP in its infancy, it's time to learn now what to expect when it matures and people are really starting to use it for the information that it will provide access to.
I saw some really nice tools for managing OLAP information output from OLAP@Work, AppSource (www.appsource.com) and others at the show, but when asked, most just indicated that they sit on top of the OLAP output and capabilities of SQL Server - you have to build the source before you can analyze it. This is your call to action - get out there and be ready when the call comes in to produce the OLAP cubes and data structures needed - know the server requirements, know the load balancing, be prepared.
I would humbly suggest that if you're not all over OLAP. Reading, studying, learning, using and doing work with OLAP quietly in the background while others are only talking about it, you're not only missing out, but possibly jeopardizing your position.
Here are some great places to start:
Microsoft's OLAP site
SWYNK.COM's list server
SQL Server Magazine