Welcome back to part 2 of MDX Code Development for Beginners. In part 1, we looked directly at the basic SELECT FROM clause in T-SQL and converted it to the SELECT ON COLUMNS ON ROWS FROM which is the equivalent in MDX. In part 2 we will be looking into the different BASIC filters that can be introduce into the SELECT statement in comparison to T-SQL “WHERE” clauses.
Oftentimes, I am presented with queries from a client with a myriad of joins that have no table aliases. In order to improve performance, I often will have to create temporary tables from pieces of the query, and sometimes they need to be created manually as opposed to performing a SELECT INTO. Having to search through all of the tables through the GUI manually to determine the proper information on the columns can be quite a pain and a waste of time. In an effort to better utilize my time, I created a simple query that will return where the column resides as well as everything you need to know about the column and more.
I recently was tasked with a project to consolidate several SQL 2005 database servers down to one existing SQL 2012 database cluster. While working on this project, I found that one of the database servers needing to be consolidated was utilizing SQL Server Reporting Services (SSRS), but the existing cluster was not configured for Reporting Services. SSRS is not cluster aware, so adding this feature to an existing clustered instance is not straightforward and will likely lead to a rule check failure on the “Existing clustered or cluster-prepared instance” rule. Well today is your lucky day, as I’m going to show you exactly how to get beyond this error and on your way to making your SSRS cluster aware!
In the world of big data, we are always trying to lighten our storage footprint. Luckily for us, Microsoft has introduced data compression as an enterprise-level feature to aid in conserving storage. Not only are you able to save on storage, you will also dramatically reduce the number of I/O requests. Knowing that the disk subsystem is the slowest part of our environments, these fewer I/O requests needed for retrieving data will lead to an increase in performance.
Recently, I’ve been asked by a couple of prospective clients how RDX’s service delivery model is the correct choice for their company and their specific environment. It hasn’t been a question that I’ve honestly pondered before until lately; all I really thought about prior to getting asked this question is that we aim to strive to do the best for all of the clients that we work for and with, and that we do a great job at it.
As business intelligence continues to make a big splash into businesses, SSAS and cubes are becoming a requirement. One of the limitations that DBAs face every day is converting from reading and writing T-SQL statements to being able to read and write MDX with ease. In order help others who may have been thrown into the role, I am going to start a series on MDX code writing. This blog post will be geared towards translating a simple T-SQL SELECT statement into an MDX SELECT statement.
I have found that database snapshots are under-utilized and wanted to show an example of how efficient it is to use them prior to a code deploy for the purpose of recovering a single table or reverting an entire database from a snapshot in the event of unexpected functionality within an application.
Recently, I was tasked with building a hierarchy using multiple dimensions. I was advised to use a named query or materialized view to accomplish this because SSAS doesn’t have the capabilities to read the columns/attributes from multiple dimensions. Since I have done this before, I decided to take the AdventureWorks database and give a step-by-step tutorial of how to accomplish this request. Let’s get started!
During your life as a DBA, you will probably have to restore the master database and all the user databases on a new operating system to bring an already existing SQL Server instance online. One of my clients recently had an issue with hardware failure. Our only option was to install SQL Server on a new OS and use the backup files to restore all the databases from the old SQL Server instance. Once the new system was completely built and we restored msdb, we noticed that some of the SQL Server Agent jobs began to fail. Below is the error output from the job history. It states that the CMDEXEC subsystem failed to load.
Have you ever built a dimension in SSAS and received a blue informational warning advising you to:
In effort to clean up database environments, we as DBAs are often asked to either move tables to a different file group or to consolidate multiple filegroups and the number of database files into one. The recommended way of accomplishing this task is to drop and create a clustered index on the new filegroup; however, whenever the clustered index is also a primary key, this process becomes very inefficient and resource-intensive since we have to drop all of the foreign keys, the clustered primary key, and then recreate the clustered primary key and all of its dependencies.
Recently, I had reports from one of my clients that many of their users were experiencing slowness. While investigating, I found the root cause to be a key lookup on a single function execution, completely unrelated to the activities being performed by the users. A key lookup can be a costly operation that requires additional I/O and ultimately negatively impacts performance. As we all know, the disk subsystem is the slowest part of our environments, so eliminating key lookups when you can and decreasing the amount of I/O will have a positive impact on performance.
As a database administrator, I have encountered many occurrences in which a business user has asked to provide the number of rows for tables within a database. If you haven’t been asked yet, I’m sure the time will come. When it does, I have a script that you can add to your toolbox that will allow you to fulfill the request!