Webcast: Do It Right: Best Practices for Analysis Services 2005 and 2008
Are you seeking practical, in-depth technical advice for building a BI solution using SSAS? Analysis Services changed tremendously with the advent of SQL Server 2005. It introduced a new way of building dimensions and cubes that required a new way of modeling the solution. This session examines the best practices for properly designing cubes for performance and usability. It discusses some high-level topics but also looks at advanced topics such as alternative approaches to many-to-many dimensions, SCOPE statements, aggregation design, scalability issues, processing techniques, server properties, and more. Craig Utley has been working with Microsoft€™s BI products for 11 years and is a former Program Manager with the SQL Server Customer Advisory Team (SQLCAT), where he worked with some of the largest Analysis Services installations worldwide. In this session he brings his real-world experience with large, complex SSAS projects and presents best practices uncovered as companies deploy and use Analysis Services. Presented by: Craig Utley Sponsored by: SQL Sentry
> Register Now
> Live date: 12/8/2010 at 12:00 Pacific
Still Using What Amounts ot Hunt and Peck to Find Code Issues?
There is a very cool tool out that lets you *visually* work with SQL Server to tune, test code and see what’s really happening in your systems. If you’re working with SQL Server the old way (hmmmm, I wonder what happens when this runs??), you really should take a look at this – see if it’ll help in your shop. There’s an incredible deal now too on the tools (save literally thousands) – so for sure worth taking a look.
Get more information here
Featured Article(s)
TSQL 103 Part 1 of 2
Getting started with Stored Procedures, the benefits of them and much more.
Featured White Paper(s)
An Introduction to Workload Tuning
Workload Tuning is just what it sounds like: tuning the performance of all processes that comprise a database workload in one… (read more)
Test CLR Code in SQL Server
I don’t have a lot of opportunities for writing or testing CLR code to be run in SQL Server. The reasons are purely pragmatic, not based on security concerns or the like. Frankly I have other layers where I can do a lot of work that fits well in Dot Net code without having to burden my database servers.
There are times I want to extend the capabilities of SQL Server where the database engine is the best host for those modifications. I especially liked using User Defined CLR Types before SQL Server 2008. I had my own compressed data type, time without date type, date without time type…those kinds of things which are now part of SQL Server 2008 natively.
One of the things that is difficult to do when working with CLR code in SQL Server is to test the code. In-line debugging is not available except in certain configurations of Visual Studio.
I have found that you can use NUnit to test your SQL Server CLR code just as simply as any other .net code. If you are not familiar with NUnit, it is a code library that you can include in a project, allowing you to execute unit tests. Those unit tests may exercise the functionality contained in a Dot Net function, user defined type, etc. you may be writing for your database before even deploying the DLL to SQL Server. It saves me a lot of time.
For those of you using SQL Server Integration Services (SSIS) that are also writing Dot Net methods for some requirement, NUnit again works to help you test your code that can’t be run through a debugger.
Run a google search for NUnit. It is open source code you can use freely. It will save you lots of time.
Do you other tips for testing and maintaining your SQL Server Dot Net Code? Drop me a note at btaylor@sswug.org to share it with the rest of our readers.
Cheers,
Ben