Year: 2019

Posted on

Does managing database server farms differ from database instances?

We all experience how the number of database instances keep growing (especially SQL Servers) in the last few years.

Managing tens of server instances is commonplace, but more and more DBA’s are tasked with managing hundreds or even thousands of instances – and there is no end in sight for the growth of instances.

How does this affect us? Will the same tools and methods we used when we were managing a handful of instances scale up to meet the challenges of managing large database server estates, or do we need to develop new and more efficient methods and tools in order to meet the challenges?

In dbWatch we have spent a lot of time working on this type of questions, working closely with some of our largest customers who typically have estates ranging from a few hundred to thousands of instances, mostly SQL Server, but always including a mix of other platforms such as Oracle, PostgreSQL, MySQL or others, on-premise or in hybrid cloud scenarios.

First, we thought simply making tools that would scale up to handle thousands of instances was enough. It isn’t. We still could not see the forest for all the trees. We needed new functionality that let you analyze and manage the entire estate, or parts of it. So, one of the first conclusion we reached is that we need to differentiate monitoring/managing instances from managing the entire estate. It is simply two different tasks needing separate tools.

Managing and monitoring database instances focus on optimizing performance and uptime of the individual instance. It is usually event-driven – alarms, warnings or complaining users lead you to investigate and take corrective action. This is very often the everyday firefighting so many DBA’s spend their time with, going from one instance and crisis to the next crisis.

Database server estate management is very different. The objective of estate management is to provide overview of all resources, inventory and insight information to aid in capacity and performance planning and information to plan and prioritize DBA tasks and projects.

Overview: The first thing we need in estate management is an overview of all resources. That includes a full inventory of all servers and instances, information on each instance such as version, memory, disk, CPU, and status. Automatic scanning of subnets for new instances will aid in creating and maintaining complete inventories.

Resource utilization: Compare actual allocation of disk, memory and CPU to actual utilization of same resource.

Performance indicators: For the entire estate, see which instances are suffering the most from heavy loads, and which are lightly loaded, idle or simply no longer used.

Based on all this data you will need tools to analyze and utilize the information. You should be able to sort the data on any parameter, like pivot tables in excel, so you can find answers to questions like:

Which servers are the most heavily loaded?
How many SQL Server 2008 do we still have?
Which servers are no longer in use, or idled?
Which servers need more memory the most?
Which servers can we “steal” unused memory or CPU from?

Planning: We can also use this information to monitor long-term growth in resource consumption – disk, CPU or memory and use it to predict future requirements and make plans and budgets accordingly. Short term it will aid in allocating DBAs to the jobs that will be most beneficial to the overall resource utilization and performance of the estate.

Estate management is proactive. It is concerned with optimizing resource usage across the estate. You want to identify where you are short on resources, be it disk, memory, CPU or other, and identify where you have under-utilized resources. Based on this you can identify and plan reallocation of memory or CPU resources, where you can consolidate or decommission servers, where you should split out servers to improve performance.

What we now see on large estates is that we use the global dashboards to analyze the estate and plan work so that we can optimize DBA time to work on individual instances where it will have the most value and effect.

This is a more structured and pro-active workflow that focus on optimizing resource usage and DBA time for the estate.

This is a topic Per Christopher, one of our Sr DBAs, discussed in this webinar held for PASS DBA Fundamentals group. He also shows more examples of estate monitoring and management in these videos on estate capacity and performance management.

Posted on

Managing SQL Server farms..

On October 15, 2019, Per Christopher held a webinar for the DBA Fundamentals virtual group in PASS about managing large database server farms. He compares how going from a small family farm to a large industrial farm compares to going from a handful of SQL servers to large database server farms, and looks at how you will need to update your mindset and tool set as the farms grows:

Managing: SQL Server farm management vs single instance management

Most DBA’s are cowboys, but there is much to learn from the world of cow hearing and dairy farms that can make us manage SQL Server instances in a better way. SQL Server farms are the future of large scale database management, and we will teach you the ropes. Introducing the FarmQueryLanguage brings another dimension of control to large scale management.

Managing large database farms requires a different mind-set and a different set of tools than what you need when you only have a handful of instances to look after.

He discusses in-depth the new challenges that managing a large farm brings on, from the way you think (see the forest, not just the trees) to how you change your focus from instance-centric performance and health to farm-centric resource management.

Per Christopher Undheim is a Senior DBA at dbWatch AS, a Norwegian software company which develops a software solution for database operations. He has over 15 years of experience in different aspects of database management on Oracle and Microsoft SQL Server platforms.

Posted on

dbWatch Powertools: Database Monitoring

The secret to monitoring data is about finding the perfect balance. Too much data and you’re drowning, not enough and an ailing instance may slip under your radar. The perfect mix will track your instance’s vital signs, putting your finger on the databases’ pulse. With these vital signs, you can quickly find out if the database is healthy, while being able to track and understand any irregularities.

The secret is to find the sweet spot with the perfect amount of data. At dbWatch we have spent years finding it. Everyone can monitor 10 – 50 instances but if you have 500 there are very few applications that handle those numbers efficiently. At dbWatch, we are constantly developing and perfecting our product making a very effective, cost efficient solution. Our customers say that we are one of the best on the enterprise level of monitoring.

What dbWatch does / Tracking and Monitoring

dbWatch software tracks information so you know what was done, and when it happened. This data helps you decide how to allocate future resources, for example – knowing how capacity will increase or decrease and making changes accordingly.

Monitoring allows you to see session history and to better understand its patterns. dbWatch monitors the important information so you can constantly know that status and health of your database. We try to give you enough information without overwhelming you with it. Alerts are used for more pressing matters which are very important for you to investigate.

Matching Databases with Applications

Data needs to be viewed efficiently. By looking at the resources an instance consumes, you can see if there are enough resources available for the instance, based on the hardware components. When we see the big picture of how an instance uses time, memory and resources, we can easily know if the instance is working efficiently.

You can also use that information to match the database with the applications. To give an analogy : if databases were cars, applications would be drivers. Consider the Mini Cooper. It’s a smart little car, but even with the best racing car driver, it won’t win a race. On the flip side, a Ferrari driven by this blog writer would not win any races either.

To have a system running optimally, we must make sure that the car and driver match. Monitoring information will help define what is needed and ensure that you get a Formula 1 Mercedes driven by Michael Schumacher when you need to race. However, if you just need milk at the store around the block, a mini cooper, driven with a careful driver, would be more logical.

User pattern

The number of users on the database also gives insight. dbWatch tracks long term user patterns. These give insight into the database. Returning to the car, if something goes wrong you can see the activity and resource consumption and when the problem happened. Did it happen at high speed / peak database usage? Or perhaps it happened when the car was parked.

This also is useful when deciding about making changes to your databases. Perhaps what was once the ‘milk run’ to the store, now has many users and needs a ‘bus’ instead of a ‘car ’ because the database is much more active. The user patterns help you see these changes and make informed decisions about what, if any, action to take.

When you can see what isn’t in use, space can be cleared for higher priority active instances. Importantly when an instance’s use in minimum, it can be taken offline or made into a read only document.

Growth rate

Every finance department likes a good budget and a careful prediction of growth rate can make you friends in finance. With a few years of tracking disc usage, you will have a very thorough snap shot of size. For example, when usage increases five percent each year, you know what to expect from that instance in the next year. This plan allows you to know how much space is needed for the coming year. You can then project the budget and make your counterparts in finance, happy.

Maintenance routines monitored

We are all guilty of deploying and forgetting – making a maintenance routine and then leaving it to work on its own, without checking in to see how effective our routine is. However, it’s important to make sure they are working after they have gone out into the ether. Some need almost no attention, while others require adjusting and tuning before they are optimal.

These are some of the key points that dbWatch can do for your databases. Email us to get further information and a free trial of our systems.

Posted on

Productivity By Automation

dbWatch was founded because DBAs wanted a better, more productive way to manage databases. The DBAs solved the problem by building tools to improve their productivity. Those original tools are the base of dbWatch today.

So much productivity is personal – a few early birds do their most effective work at 6 am, and others can’t think before 10:00 o’clock. While software tools don’t influence your sleep patterns, they do make daily routines faster and consistently productive. Here are some of our best tools that help our customers and our DBAs maintain productivity.

Automation: routine and maintenance tasks

Manual monitoring and running standard checks eats time and allows room for human error. Many DBAs use scripts to make monitoring easier and faster. But considerable time is spent creating,deploying and maintaining your own scripts.

The simplest time saving tool: automation. With automation tools, the software takes care of the daily routines with a few clicks. This includes preventative maintenance, nipping problems in the bud before they get started. Additionally, automation helps alleviate unplanned downtime, keeping users happy. (DBA Operations Refined)

At dbWatch, our DBAs find automation to be essential and simple. From the maintenance console; reports, backups and standard checks are scheduled to run automatically. Additionally, the maintenance console makes the reorganizing of indexes more efficient.

Remember that last time that someone added a server without informing you? Autoscan keeps an eye open of those pesky individuals who take initiative without telling DBAs. It continually scans for added servers and reports to you, so you’ll be able to label and account for them. Once labeled, our group, sort and tag functions, help you keep them organized.

Unified Systems

Part of doing a job effectively involves cutting down on the number of steps it takes to reach completion. Fixing problems with multiple platforms often involves signing into that platform. Granted, it’s only 30 seconds or less, but those seconds add up to wasted months and years. dbWatch unifies systems and workflows in a single platform, giving you a smooth flow from monitoring to managing and fixing issues.

The systems can be viewed and sorted together, by server names, types, platforms or your own labels. The resulting data is more meaningful, and it’s easier to identify the server you want to work with. Finally, it allows DBAs to work across platforms, with the software. If you are a SQL Server expert, you can easily take care of daily maintenance on other platforms. With a unified interface most operations are the same regardless of target platform.

Quick set up with bulk install

Finally, two small but time saving points.

Quick set-up (bulk install): When you deploy dbWatch, it only takes a spreadsheet of usernames and passwords for dbWatch to connect with your instances and immediately start to monitor them.

One License: Just like the one ring, ruling all others, one license can cover all your needs, keeping the management happy with lower costs.

The

Magic Productivity Solution is …

That there isn’t one solution. There are as many solutions as there are DBAs. We offer tools that our DBAs use in their daily routines which help them improve their productivity. Good luck with your own productivity. If you want to share a solution, just comment below.

Start your free trial
Posted on

Database monitoring in complex networks

Monitoring databases in large, distributed or hybrid environments

Monitoring database or SQL servers can in itself be a complex task – as we discuss in SQL Monitoring – 5 steps to full control. But what if you have a really complex environment, with multiple locations, restricted networks behind firewalls, high number of servers or a hybrid solution with some on-premise and some in a cloud? What are the issues, and how can you resolve them?

If you have your database servers distributed in multiple locations or networks they will often be behind separate firewalls. In addition you often have limited bandwidth or slower response time (round-trip time). Opening ports in the firewall for each and every instance you want to monitor is cumbersome and should be avoided from a security perspective.
If you have a large number of servers to monitor you run into scalability issues. There is an upper limit on the number of simultaneous connections you can have from a single monitoring server, it will have a finite number of cores and memory and too many monitoring connections can create network contention and a storage bottleneck if you try to collect and store monitoring data from too many servers at the same time
Lack of redundancy. The bigger and more complex the environment, probably the bigger the need for redundancy in monitoring servers as well as the database servers themselves

In many enterprise networks you are likely to encounter several, sometimes all of the above challenges. We find these kind of challenges common, especially in larger managed service providers (MSP) and hospital/healthcare groups. So we started to work on resolving these issues about 8 years ago, delivered the first solutions 6 years ago and have been refining and extending these ever since.

But lets be honest – we have not been good at telling our customers about this, it has been a well kept secret for all but a small group of our larger customers.

In the dbWatch database monitoring solution we have the possibility to deploy any number of dbWatch servers. Each of these servers have the following properties:

On windows, we can monitor 250 instances, on a linux platform 500 instances
The server will handle all status checks
The server triggers scheduled maintenance and statistics collection tasks
The server will cache the most recent status and stats for all the local servers

The dbWatch monitor (this is the dbWatch UI application) can connect to one or more dbWatch servers simultaneously.

In most smaller installations there will be only one dbWatch server. This server connects to all the instances that are being monitored. The dbWatch keeps an open connection to all the servers.

The dbWatch monitor connects to the dbWatch server.

When we get to more complex environments, where you have multiple locations, or subnets with database servers hidden behind firewalls, we can add more dbWatch servers. We put these additional dbWatch servers behind the firewall or in location where the instances to be monitored are located.

By using multiple dbWatch servers we get a number of benefits:

The monitor has a single connection through the firewall to the dbWatch server. This keeps number of open ports in the firewall at a minimum.
The local dbWatch server maintains the connections to all the local instances, and triggers the monitoring and maintenance tasks locally.
Network traffic between the dbWatch monitor and the local dbWatch server will only take place when the status of a local server changes, or when you run dashboards or reports on the local servers from the dbWatch monitor. This will keep network traffic to a minimum.
We can scale up to monitor almost any number of instances by adding more dbWatch servers
In the dbWatch monitor you always get the complete overview or can drill down into any instance, regardless of which dbWatch server it is connected to.
If the connection to any dbWatch server is lost, the other servers and connected instances are still available in the monitor. This adds to overall redundancy and system robustness.
when autoscanning for new instances, we can do this inside the local network or location from the local dbWatch server. Scanning for instances from outside the firewall is not desirable, and often impossible.

Over the last 10 years we have developed a range of technologies and methods to safely and efficiently monitor sql instances in distributed locations and in diverse networks behind firewalls. This is a common scenario in healthcare, managed service providers and large enterprise in general. Today we consider this a proven and common mode of operation and is frequently used by many customers.

Get started with dbWatch - 30 day free trial
Posted on

Vision for the Future: dbWatch Enterprise Manager 12

dbWatch Enterprise Manager 12

At dbWatch we believe that DBAs should be able to manage their databases using a single solution. We understand your pains because we experience them, we work through our own bugs before going into beta-testing. Because we use our own software to monitor databases, we have learned firsthand the improvements needed.

With Enterprise Manager 12, we have developed a package that gives DBAs a complete overview and platform to manage their workflow using one source. Seventeen years of building and programming database software has laid the foundation for this version.

Enterprise Manager 12 increases functionality and allows trouble-free monitoring, maintenance, performance and planning. Four consoles offer you all the tools needed to smoothly manage databases. Within most consoles, the main screen gives an overview and tabs along the top screen allow you to dig deeper into details and help you stop possible problems more efficiently. All four consoles will be available in the web server view.

Monitoring Console

Caption: Live Monitoring Console with the ‘stop light’.

For the last three years, the “stoplight” has adorned the monitoring screen, measuring the pulse of all the data bases. A stoplight indicates: green – everything good; yellow – possible problems; red – alert.

By keeping on top of the yellow notifications, DBAs can move from putting out fires to working directly on prevention and fine tuning.

Maintenance Console

Data bases are similar to cars: They both run better when they are optimised. The Maintenance Group Console keeps an eye on the car’s oil levels, tire pressure and brake fluid. This console advises you when maintenance is needed.

“We call it bullet-proof maintenance,” says Marek Jablonski, CTO. It monitors everything: re-indexing, statistics, changing routines, and adjustments. The Issues are highlighted in yellow and red, making them easy to identify.

The following five tabs aid in the Maintenance Group Console: DBCC, Analyse statistics, Reorganise indexes, Rebuild indexes, and Cleanup msdb.

Maintenance Tasks

This new solution came out of the demand for more information on maintenance routines, it allows DBAs to deploy routines and monitor how they are working. “Imagine if you are installing instances yourself – you have to manually deploy them, upgrade and collect information.

With dbWatch, you can deploy hundreds of instances and then monitor them,” says Marek. “This allows you to see if these are reporting without errors, note if there are changes in the data, and give DBAs full control beyond the implementation.”

Performance Console

Going back to the car metaphor: while the maintenance console monitors the fluid levels of a car, performance console keeps an eye on how the chauffer drives.

Here, all instances are monitored and new instances can be found. The system’s level of use is recorded and instances can be found. Alarms and warnings show the system performance and alert of potential problems.

The following three tabs support the performance console:
– File IO Latency, Waits, and DML test

Capacity Console

As its name suggests, the Capacity Console gives DBAs the information they need to plan ahead. Four tabs: Disk, CPU, Memory, and Data Cache; give DBAs optimal capacity measures.

Marek explains, “Many DBAs don’t have a system to track exactly what they have done or how well their systems have been working.” By knowing what has worked well in the past, DBAs can better plan the future.

The Capacity Console also gives DBAs important information they need to plan with a client, for example, knowing how much disk space is needed. This console covers a wide range of activities – tracking resources, growth rate, and the size of the environment. Additionally, it shows how the maintenance routes are being followed and finds patterns.

Knowing what has happened in the past is vital for planning the future. Having this information on hand allows you to have strategic meetings with clients, allowing you to show them their past history and possibilities for the future.

The New Evolution

All of these consoles with their multiple views help streamline DBAs’ workflow. They aid at many different levels, from checking that everything is running smoothly, to maintenance tasks, performance analysis or checking capacity. Those currently using updated software already have access to some of these new features.

dbWatch Enterprise Manager is released early 2019. Experience the difference of handling all your workflow from one program – find out first when we release: follow us on Twitter, LinkedIn or on our blog.
Start your free trial today! download here
Posted on

DBA Challenges for 2019 and Beyond

This year Bob’s job as a DBA has some challenging issues. His company is considering moving to the cloud, which has Bob worried about job security. The developers are interested in adopting Devops, to streamline their applications. Additionally, his boss wants more database security and decided that the system needs 24 x 7 maintenance. As if that’s not enough, there seems to be never ending demands for growth in services, solutions, data and the need for speed.

The IT landscape constantly transforms, a hill of data here, a new road through instances there, and over it all: cloudy weather. To keep up with the changes, DBAs like Bob must continually track the changes and evolve with the landscape. Currently there are some megatrends underway that fundamentally affect how we develop and manage our IT systems.

Most DBAs face challenges similar to Bob’s. They need solutions and tools to keep up with IT’s constant changes. We at dbWatch track these changes and develop tools to help DBAs. Here are some solutions for the challenges we most often see DBAs struggling with, solutions that we actively build to meet the constant changes, solutions to help people like you and Bob.

Devops

Bob asked us, “Who came up with this word anyway?” *) Well Bob, it would be nice if Devops were as simple as combining two words.

At Bob’s company, Devops is relatively new. They jumped on the Devops bandwagon recently, a year ago. Unfortunately, they are still working through some of the typical problems employees experience when their silos are whisked away and replaced by new diverse teams.

It’s been a rocky road, the developers still usually insist on “proof” before believing that there’s an error in their system. The DBAs continue to use custom scripts and specialty tools that they have built themselves. “Overall,” Bob says, “It feels like half the team members only speak Ewokses and the other half only know Droidspeak. We need to find a Galactic Basic, which everyone can use to understand each other.”

While we may have a drone Millennium Falcon, we don’t claim that dbWatch can solve galactic communication problems. However, we can help developers and DBAs find a lingua franca.

dbWatch gives the developers and DBAs a common a platform to see and test application behavior. This gives everyone insight and control into how the database engines are performing with advanced views. Developers have clear insights to application behavior throughout the development and test stages, while the DBAs can keep a constant eye on developments, ensuring nothing has taken a sudden turn in the wrong direction. “The role of the DBA in light of DevOps and Cloud Migration“ describes this in more detail.

*) By the way, Devops, (devops or DevOps) is attributed to Patrick Devois, who coined it as a hashtag in 2009. Devois spells it Devops, we’ll leave the fight over the capital letters to the code writers.

Database Security

With all the case-study horror stories about security breaches, IT operations managers obsess about security. This trickles down to Bob as a DBA, he is relieved that dbWatch can elevate several issues. Role based access controls and Active Directory (AD) integration makes it easy to grant and revoke limited access. On a lower level, dbWatch’s ability to distribute monitoring servers behind firewalls and use secure encrypted connections makes for a more structured and secure database access while helping implement the company’s security policies.“Security considerations in database operations“ is an article going into more details on this.

We’ve recommend that Bob’s company have a trial of dbWatch. Our other clients have found that the user access controls saved them time and energy. “You’re able to define a role for the DBA by which accesses are allowed,” explained Marek Jablonski, CTO at dbWatch. “For example, a part-time DBA would only have access to a few functions, others might have limited roles or even simply read-only access.” In addition, the DBA can track what is happening within the system. “You can define access by time of day, calendar dates, activities, placement, almost anything,” Marek said.

Bob looks forward to the insight and overview this will give him, allowing him to control the system and free up time to work on things that need his attention.

Cloud Migration

Cloud strategy – or lack thereof – can make or break a company, having serious financial and business impact. On one side, the cloud offers agile scalability, allowing businesses to grow and meet peak demand quickly. On the other side, if everything is moved to the cloud without critical planning, it could have a significant economic impact. When something looks too good to be true, of course it isn’t true – a move to the cloud does not solve all your problems.

With Bob’s research, he already knew that he would still be responsible for managing the migration, sizing resources to optimize cost and monitoring the performance. He knows that too little resources and the solution will not perform well. Studies have shown, 8 seconds wait time is about maximum of what customers will tolerate before leaving and that number is coming down. But, when too many resources are used to keep up fast performance, costs can run amok. “Extending database monitoring into the cloud“ is not without problems as is discussed there.

We know that on the cloud control will be even more critical than before. Bob might not need to worry about backups anymore, but he’ll need to monitor performance (and cost!) closer than ever. The cloud is on the meter, and that meter can run fast.

Our solution for cloud-control: being able monitor all database resources in a single view, regardless of where they are located. One dbWatch view shows all instances: on-premise, Azure and any other cloud. This gives all DBAs the insight and control needed to manage performance and make qualified decisions between what to run locally and what should migrate to the cloud. Having some databases thoughtfully selected for the cloud will free Bob up to have more time for other projects. However, all clouds are not created equal. There are somethings he needs to watch out for, especially when it comes to Azure.

Azure

Most cloud databases function like normal databases. Azure databases are a bit different. It manages the database for you. “It’s not so clear what’s happening when you’ve moved things off-premise,” says Marek. “You just have to trust them.”

Azure offers very little insight into what is happening, making the DBA’s job of monitoring Azure, checking performance, response times and indexes, vital. dbWatch researched Azure performance speed and found some interesting results, including the fact that their performance measurement, DTU, is rather vague. One inch is always 2.54 cm, but no one, including Azure, explains how a DTU relates to anything but other DTUs. “It’s a purely synthetic measurement,” says Marek. “One DTU is a rather tiny performance, maybe similar to a microcomputer like Raspberry Pi.”
If you’re interested in the Azure performance issues, you can read this blog, or download the full Azure research paper here.

24 x 7 operations

While Bob is no stranger to 24/7 operations, it is new to have all aspects of the company working around the clock, with colleagues and customers working at all timezones. His current biggest challenges are: intensified monitoring needs and good automated distribution of alerts and warnings, depending on time of day and week. Last year he missed out on detecting an incident and just managed to catch it before a major disruption; naturally he wants to avoid this happening again.

Here dbWatch offers Bob a practical fast solution. He understands from problems with his semi-automated monitoring that he needs a fully automated system. We can offer him one step further in solutions, distributing the information gathered in the system in a fast and efficient way to the correct person at the correct time via the best channel. Also, when Bob’s in office when an alert comes in, he can simply change to dbWatch management mode to fix the problem

Because Bob is the senior DBA in his company, he usually ends up on-call. He can configure dbWatch monitoring to catch the serious issues when he’s out of office and send the alert to the frontline monitoring, telling them to call him if a specific alert comes in.

Growth and scalability

Growth in complexity and numbers does not automatically mean more DBAs. DBAs are expected to evolve and become more and more efficient all the time. Full-time DBAs today are expected to manage much more than a handful of servers/instances.

Since Bob started working for his current employer five years ago, there has been between 10% to 25% growth each year. Earlier, Bob’s job was like managing a small taxi company, now he’s expected to coordinate a city-wide public transportation network. It goes without saying, Bob has to run the public transportation network using the same staff he had in the small taxi company.

This large-scale operation requires better tools than what’s currently in his tool box. dbWatch’s tools give overview and insight to name, group, sort, organize and report in addition to managing instances. “What works for a handful becomes too labor intensive and repetitive when faced with several hundred instances. It’s like going from managing a single race car to being responsible for a city-wide public transport network,” Andreas, CMO at dbWatch, says, “We often see DBAs handling hundreds of instances each, and sometimes multiple platforms as well.”

Scalability is becoming a real issue in many enterprises and is and issue we pay a lot of attention to. We discuss this further in “Why scalable database monitoring is a must for growing businesses” and “Understanding database scalability – a 101 guide“. 

 

In Conclusion

In the time it’s taken you to read this article, likely something in the IT landscape has shifted ever so slightly already. Constant change is the new norm. This story has examined the areas which we see most affecting our clients and our own DBAs. We focus on these areas, helping to deliver better solutions and tools.

By the way, we could reassure Bob that his job isn’t in danger. First, Bob has something that will ensure his continued employability: the ability to embrace change. DBAs who can change with IT, seeing it as a challenge rather than a barrier, are resilient and likely to remain employed. In addition, Bob works on complex DBA jobs, so his job is unlikely to be threatened by the latest level of developments.

Final Words

So, is this all? Of course not! If you have questions about dbWatch solutions or have suggestions for other areas where we could make a difference for DBAs please let us know. We would love to hear your opinion. Drop us an email at info@dbwatch.com

***

Who is this Bob person?

Bob is a mix of several of the clients we work with, including some of the DBAs on our team. While he is a fictional character, we and our clients have all experienced similar problems.

This blog post was contributed by Rebecca Harrison.

Rebecca Harrisson writes and helps people communicate clearly by day and is a folk harpist and storyteller by night.  She writes for IT companies and harp magazines.  You’ll find her on LinkedIn.

 

Standard-Logo (17)

Complete database Monitoring and Management solutions

CONTACT INFORMATION

+47 22 33 14 20 (Oslo)

+44 020 7692 8971 (UK)

sales@dbwatch.com

dbWatch AS

Nedre Slottsgate 4M
0153 Oslo, Norway

 

 

© 2023 dbWatch AS