The dbWatch Blog

dbWatch Enterprise Manager 12

Complexity is often a natural condition of most successful businesses. We build databases to handle complex data, tomaintain a layer of structure for important business information.However, when building a database, or cluster of databases, typically the needs or requirements change over time. Newdivisions or projects spring up. This is generally not a bad thing for a business or organisation. In most cases growth is good. However order to do this, without incurring huge amount of expense, often you a add these modules into existing...

One of the primary features of a successful company is growth. In the earlier stages, you started working in a relatively simple environment. Maybe you had a few separate databases handling a few functions. Typically, these handled data for maintaining and managing products, employees, and sales.

Dealing with a wide variety of databases, platforms and versions is a reality for many companies. While it would be nice to be able to have one platform to handle all tasks necessary within an organisation, the reality is that different needs require different solutions. As a result, we create (or at least are forced to work with) diverse systems.A variety of systems can be great for providing solutions which might not be easily available within one database platform. Unfortunately, this diversity also can bring unwanted complexity to the...

The goal of any organisation, business or otherwise, is to grow. In the past, the size of a company was determined by the number of physical products that one either created or sold. Say you built and sold left-handed toolboxes. If you sold enough of these left-handed toolboxes, and if they were of good enough quality, more people wanted your toolboxes, so you created more. With this growth, was a need to keep a record of these products, customers, sales, etc. Companies simply kept records in pen and paper, in stacks of ledgers. Soon these...

In theory, managing a database should be a relatively easy process. Once you've designed it, normalised your data model, and loaded the data, it should run pretty well on its own. However, theory rarely matches reality. There are, of course, many day-to-day tasks, such as tuning performance and rebuilding indexes when they get lost. These add layers of complexity, which only grow as the database gets larger. Add to this the likelihood that the number of instances you need keeps growing, and you see your time for other tasks rapidly becoming...

You have a solid database architecture. You spent all the requisite time needed making sure your models are normalised in a way to provide the cleanest structures. However, reality being what it is, there are occasional problems. Rarely is any database complete and perfect the first time it is deployed. Sure, you can handle any problems that arise at first; every now and then something doesn't run the way it is supposed to. You can see most of what you need through a quick examination of the logs; there are few slow-downs, but for the most...

One of the more popular products currently on the market is SQL Monitor, a product designed specifically for working with SQL Server. Its success is largely due to its ease of use and accessibility to those without professional DBA training. It works reasonably well for those used to working solely within Microsoft's product environment. As many companies have corporate policies to work specifically with Microsoft as their main, if only, product platform, it's a helpful tool.

For many people, the idea of an all-in-one tool suggests a lack of quality. People mistakenly think that by opting for a wide-ranging one-size-fits-all toolset, they’ll be sacrificing quality compared to adopting bespoke specialist tools that have been designed to fit a niche.

Every one of us is familiar with the pain of repetitive, mundane tasks. From regular server maintenance and cleanup to running reports and monitoring software, there are many tasks that DBAs face every day which take up too much of their time and effort.