My previous blog post was about the SSIS Lookup task and how it really works. Now that I have shown that the Lookup task shouldn’t be used for one-to-many or many-to-many joins, let’s take a look at the Merge Join transformation task. If you follow along with this blog, you will learn a little tip that will eliminate the requirement for you to add a SORT transformation task within your data flow task.
Circa 1988. I entered the technology space, writing SAS/JCL on an IBM 3270 for the Federal Government. There was something missing though. Countless merges, duplicate data filtering and large data sets all seemed like a horrible waste of resources and, more importantly, time. Not only that, SAS user guides filled my entire cubicle, making it nearly impossible to evolve the skill set quickly.
One of the main benefits of an AlwaysOn Availability Group is being able to read off of the secondary replicas. However, Read-Only Routing is not automatically configured when you first build your AlwaysOn Availability Group. To fully utilize an AlwaysOn Availability Group and take full advantage of having read-only connections connect to your secondary database, you will have to configure Read-Only Routing.
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 technology advances and organizations grow, cloud computing and hosting are becoming a part of our organizations more and more. One of the new offerings by Microsoft is their Azure platform with one of the services being the Azure SQL database. While working with the Microsoft Azure platform during a recent project, I discovered the ability to name your own Azure SQL server in the Azure Preview Portal, a feature that isn’t available in the Azure Management Portal. I’d like to share this feature with you.
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.