As the modern database continues to evolve and take on a more strategic role in business, the complexities associated with managing these environments grows as well. For database administrators, this changing landscape forces them to continuously adapt and grow alongside the database engine to properly design, support, and secure an enterprise’s critical data stores. Their in-depth knowledge of the infrastructures so crucial to operations make DBAs an integral part of not only day-to-day functions, but business decisions aimed at reducing operation costs, improving margins, and more.
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.
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.
In this next article of the series, we’ll continue our comparison of relational and NoSQL schemas. Part one of the article used MongoDB as our subject for comparison. This second article uses Cassandra as the representative for NoSQL architectures.
In this next article of the series, we’ll analyze the different strategies that the Relational and NoSQL database vendors follow for schema design. This will be a two-part article with the first using MongoDB as our subject for comparison followed by a second discussion using Cassandra as the NoSQL product representative.
As the strategic role of databases continues to advance within organizations, the task of finding and retaining experienced DBAs has become increasingly difficult. DBAs are seen as the “Go-To” specialist for internal IT teams due to their knowledge across a wide spectrum of information technology and processes. In an increasingly complex environment, database administrators design, support, and safeguard a company’s critical data stores, ultimately allowing organizations to make better business decisions.
In order to compare relational and NoSQL architectures, we must begin with their historical roots. The focus of this article will be on the business drivers that led to each architecture being readily adopted by the IT community, as opposed to an in-depth historical essay on each model’s technical genesis. Describing why the products became popular provides us with the opportunity to perform a high-level analysis of the relational and NoSQL models and architectures.
The intent of this series of articles is to perform a technical comparison of relational and NoSQL database offerings. Unlike many articles that you’ll read, it is not intended to sell readers on a particular vendor offering, nor will it favor one architecture over another.
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.
After years of having their own internal processes, technology, and best practices, it’s understandable some organizations have trepidation when it comes to DBA outsourcing. Especially for companies with internal teams, concerns arise regarding how external support will fit in with their current DBAs and the methods in which they operate. At RDX, our customer on-boarding process is focused on easing these concerns and building a solid foundation to provide a high level of remote database services based around the needs and challenges of your infrastructure.
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!
IT professionals can attest – the world in which we operate changes rapidly. For database administrators, it can be a blessing and a curse all at once. With technology continually advancing, database vendors are forced to implement new features and functionalities in order to stay competitive. Each release contains dozens of advancements and new additions that can potentially be leveraged to improve the database environments they manage. Part of what makes being a DBA so rewarding is the ability to evaluate and understand these inherent features, choosing to implement those that pose the greatest benefit to each application.
I use the title "Data Administrator" loosely to describe the functions these IT specialists provide. I use it for clarity only in this article because I think it oversimplifies the important role they play. Data Administrators are more aptly titled "Protectors of the Organization's Critical Data Assets." From establishing proper naming conventions to implementing corporate-wide data management policies, the services they provide range the spectrum.
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.