About the Author:

Chad Pabalan is a Pre-sales Engineer for dbWatch and a DBA who specializes in SQLServer high availability setups and disaster recovery planning and configurations. He is an AWS Certified Solutions Architect Associate, a cloud enthusiast who specializes in architecture and designing scalable, high available, and fault-tolerant systems on AWS

----------------------------------------------------------------------------------------------------------

About the Author:

Rey Lawrence Torrecampo is a Pre-sales Engineer for dbWatch and full-time Database Administrator. He has extensive knowledge in Postgres and MSSQL database management systems with SQL as his most proficient language. Coupled with his experiences in Data Science and data migration, he has confidently handled roles in data migration job developments, data analytics and data cleansing.

----------------------------------------------------------------------------------------------------------

About the Author:

Lukas Vileikis is an ethical hacker and a frequent conference speaker.

Since 2014, Lukas has found and responsibly disclosed security flaws in some of the most visited websites in Lithuania.

He runs one of the biggest & fastest data breach search engines in the world - BreachDirectory.com, frequently speaks at conferences and blogs in multiple places including his blog over at lukasvileikis.com.

----------------------------------------------------------------------------------------------------------

About the Author:

Lukas Vileikis is an ethical hacker and a frequent conference speaker.

Since 2014, Lukas has found and responsibly disclosed security flaws in some of the most visited websites in Lithuania.

He runs one of the biggest & fastest data breach search engines in the world - BreachDirectory.com, frequently speaks at conferences and blogs in multiple places including his blog over at lukasvileikis.com.

----------------------------------------------------------------------------------------------------------

About the Author:

Lukas Vileikis is an ethical hacker and a frequent conference speaker.

Since 2014, Lukas has found and responsibly disclosed security flaws in some of the most visited websites in Lithuania.

He runs one of the biggest & fastest data breach search engines in the world - BreachDirectory.com, frequently speaks at conferences and blogs in multiple places including his blog over at lukasvileikis.com.

How is database farm management different from instance management? Why do you need it and when? That is what I will try to shed some light on in this blog. If you are responsible for a database farm, read on.

Managing instances – watching and tuning performance, handling incidents, and generally maintaining them has always been the DBA domain. DBAs are focused on the database server performance now. As the number of instances grows, you will need more DBAs to handle the job of keeping all instances ship-shape daily. This is when you need to consider farm management as well.

Managing the database server farm is about managing and optimizing resources, cost, risk and inventory, planning, forecasting, reporting, and budgeting. Database Farm Management is focused on the medium- and long-term future, so it is usually done by senior DBAs and IT operations managers.

As an analogy, think of the difference between database farm management and instance management as the difference between managing public transport in a large city with managing a formula one race car team. The former is concerned with moving as many people as possible on buses, trams, and trains in a cost-efficient manner, while the latter is concerned with making one or two cars win the race at almost any cost.

Problem 

You are hired for a new job as a Senior DBA but the previous DBA who just left the company didn't provide the complete documentation of the existing database instances. You need to get a full overview of all instances, retrieve and document all the database instances available within the enterprise network. How could you accomplish this task? 

Have you ever found yourself in the situation where a you have to take over the responsibility for a database server farm, but where documentation and overview is missing or you do not trust it to be up to date? You want to get a full overview of all instances, retrieve and document all the database instances available. How could you accomplish this task most easily? 

Solution

If you happen to run dbWatch Enterprise Manager or dbWatch Control Center, you are in luck. 

dbWatch is capable of tracking and listing all instances within a specified network range.  

dbWatch has a built-in Autodiscover feature for these situations, whether you need to create an overview from scratch, or you want to monitor your networks / subnets to see if new instances are added, then you can add all the discovered instances in your dbWatch monitor and group them accordingly. 

In this blog, you can learn how you can configure and automatically discover all instances within a custom network range which you will specify. You can also learn how to add the discovered instances in the dbWatch monitor. 

Database locks have been a bane to most DBAs. They cause unnecessary problems to database and business processes. In this blog, we will examine what database locks are, issues that can arise from it, and provide ways on how to deal with it on SQLServer. Not only that, we will also implement it in dbWatch Control Center as an example.

In this blog, I will discuss SQL Servers’ database compatibility level. By using dbWatch, we will check the proper setting and configure the right compatibility level based on the version you are using.  

Each new version of SQL Server introduces new functionalities and performance benefits. These are identified by compatibility level and cardinality estimators.  

The New Normal solidified the preference of online transactions. From banks, retailers and food industry, Information Systems have adapted with the times to comply with the customer’s demand. However, not everything is dandy in this period of a new normal. With the increase in demand, this certainly merits a degradation in your database performance. Most common of this occurrence is slow running database that is visibly seen on top of applications.