Operations | Monitoring | ITSM | DevOps | Cloud

In software terms, “open source” means applications and their source code are available for the public to download and modify free of cost. Anyone can access, edit, and supplement the code to create an enhanced version of the application. Vendors often do this by forking the source code to create their own version of the application, marketing their version commercially.

SQL Server monitoring is continuous collection and analysis of usage, performance, and event metrics for Microsoft SQL Server. It’s the first step in optimizing performance for applications that depend on your data platform. Highly effective monitoring gives a bird’s-eye view of your entire data estate. It also provides the deep analytics necessary to perform root cause analysis on the most challenging performance problems.

Managing any database ecosystem is difficult enough: taking backups, maintaining statistics, and doing performance tuning all tax the time of the DBA or database developer. The job is complex even without considering the work you do to manage the various schema and data drifts that can occur. Unless you operate in a vacuum or within a single person organization (and even then, schema drift can occur), drift is going to manifest naturally and as the size of the environment expands.

When drift happens within a database, it can occur at a couple of different levels. Drift refers to entities—tables, views, or even data—out of synchronization with each other. This could be a difference in schema structure, data, or even operational metadata like permissions. Often, drifts happen between two different environments like development and staging databases.

Investigating your family tree can be an interesting experience. For example, what if you discovered you were related to a famous person who won a Nobel Prize or performed a heroic act? Conversely, what if you realized you had an ancestor who was an infamous criminal? Much like examining your genealogy can be an exciting adventure, looking at the family tree of your database can prove to be just as rewarding. Databases occasionally undergo a phenomenon known as drift.

That’s what they say. Bring it on. I’m ready for this. I’m prepared. But no one could prep for what happened and how things evolved, right? So is preparation not necessary after all? I’ve had numerous discussions with my colleague and fellow Head Geek Leon Adato about this topic, and we even created a video with the background theme of preparation vs. instant action. Leon is kind of a doctoral student in chaos theory—or so it seems—while I try to plan things out.

One of the easiest ways to increase query performance in SQL Server is to make sure it can quickly access the requested data as efficiently as possible. In SQL Server, using one or more indexes can be exactly the fix you need. In fact, indexes are so important, SQL Server can warn you when it figures out there’s an index missing that would benefit a query.

We may be biased, but we think we’ve had some great blogs that are informational, impartial, and (hopefully) not boring to read about all things related to what’s happening on the internet. Looking back at our blog—dating back to 2006—one series saw the limelight from 2012-2017: the state of the internet series.

“Cloud-first” has been a government imperative for many years, but the pandemic usurped this strategy, making “cloud-now” a priority. The results have been transformational. The cloud made wide-scale government telework possible, but it’s also given agencies the opportunity to test drive new cloud applications and experience the scalability and security benefits first-hand.

Ideally, database queries use the fewest possible resources: time, memory, bandwidth, etc. Lower resource consumption maps to better query performance. To find relevant data in a table, a database query relies on lookup operations, and a table index can help a query efficiently find the table values it needs. With an efficient, well-designed table index, a database query can find the table data it needs, avoiding the need to "scan"—or search through—all the table data.