As part of the service that as a WellData client you receive, we anticipate problems, we think ahead and apply ‘fix-before-fail’ procedures to proactively test, monitor and reduce the risk of things going wrong to the very minimum.
And this may be why you don’t need to contact your WellData DBA every day.
But does this mean that there is no activity carried out on your databases?
No, in fact, quite the opposite.
Our proactive DBAs achieve this by implementing some key tasks:
However, at WellData we believe that this still isn’t enough.
And that’s why we also ensure that your assigned WellData DBAs regularly perform an additional series of tasks to help ensure that your database is at the highest standard…
So, when you receive updates on any of these tasks, you know that while these are not always routinely performed tasks, WellData carry them out as standard.
You can enjoy the peace of mind of knowing that your databases are proactively managed, with minimum disruption, and that’s why you don’t need to hear from your proactive DBA all the time.
Regular user permission reviews should be part of a regular database health check, but in our experience, clients rarely actually carry this out.
In fact, we have seen many instances where employees have left but still have user access and enabled accounts.
Sometimes clients are scared of deleting the user, fearing the possible dependencies on that account, but they don’t realise the potential threat that leaving access to their mission critical databases to an ex-employee can mean to their business.
That’s when we step in and help our clients review their security, disabling accounts when relevant.
Identifying databases that are no longer in use is harder than it sounds.
It involves closely monitoring the databases, taking them offline, ensuring that this hasn’t caused any disruption and only when you are absolutely certain that nothing will break down, the database can be removed.
The benefit?
Left untouched, these databases would still require maintenance and back ups, using unnecessary system resources and capacity.
Similar to databases being left in service when they are no longer used, we often come across scheduled jobs that have been disabled or are no longer running.
These should be deleted, and that’s why we work with our clients to ensure that the job is definitely not required and can be safely deleted.
Regular user permission reviews should be part of a regular database health check, but in our experience, clients rarely actually carry this out.
In fact, we have seen many instances where employees have left but still have user access and enabled accounts.
Sometimes clients are scared of deleting the user, fearing the possible dependencies on that account, but they don’t realise the potential threat that leaving access to their mission critical databases to an ex-employee can mean to their business.
That’s when we step in and help our clients review their security, disabling accounts when relevant.
Identifying databases that are no longer in use is harder than it sounds.
It involves closely monitoring the databases, taking them offline, ensuring that this hasn’t caused any disruption and only when you are absolutely certain that nothing will break down, the database can be removed.
The benefit?
Left untouched, these databases would still require maintenance and back ups, using unnecessary system resources and capacity.
Similar to databases being left in service when they are no longer used, we often come across scheduled jobs that have been disabled or are no longer running.
These should be deleted, and that’s why we work with our clients to ensure that the job is definitely not required and can be safely deleted.
If you are considering a project or have an additional requirement that we can help with, please get in touch.
These tests can be run in addition to the traditional database backups.
While the backups allow you to recover the database if it becomes unavailable, at times it can be difficult to know where the backup file can be restored from, and to be sure that the backup file is useable.
Obviously there are things like backup checksum and backup verification for SQL Server or RMAN validation for Oracle, that can give you a pretty good idea that your backup file is ok – but the real assurance only comes from actually running restore tests from the backups to make certain that, should the worst come to the worst, you will be able to effectively recover your data.
To run the restore tests you will need additional resources, like a server dedicated to backup tests, the end result is worth the investment.
When we take on a new client there is often little or no documentation on which applications use which databases and, particularly for larger businesses, this can cause severe delays in solving application issues.
This lack of mapping makes it hard to track down the database that needs to be addressed if there is a problem with a particular application.
Once again, we can step in and work on the application-to-database mapping for our clients.
Every database version will reach end-of-life at some point and that’s why it is important that for versions that are reaching end-of-life we begin upgrade plans, including tasks such as checking for breaking changes in newer editions, and begin working on fixes.
These tests can be run in addition to the traditional database backups.
While the backups allow you to recover the database if it becomes unavailable, at times it can be difficult to know where the backup file can be restored from, and to be sure that the backup file is useable.
Obviously there are things like backup checksum and backup verification for SQL Server or RMAN validation for Oracle, that can give you a pretty good idea that your backup file is ok – but the real assurance only comes from actually running restore tests from the backups to make certain that, should the worst come to the worst, you will be able to effectively recover your data.
To run the restore tests you will need additional resources, like a server dedicated to backup tests, the end result is worth the investment.
When we take on a new client there is often little or no documentation on which applications use which databases and, particularly for larger businesses, this can cause severe delays in solving application issues.
This lack of mapping makes it hard to track down the database that needs to be addressed if there is a problem with a particular application.
Once again, we can step in and work on the application-to-database mapping for our clients.
Every database version will reach end-of-life at some point and that’s why it is important that for versions that are reaching end-of-life we begin upgrade plans, including tasks such as checking for breaking changes in newer editions, and begin working on fixes.
Millions of business databases are running without any form of proactive database monitoring service.
This is similar to running office PCs without any virus protection.
Today we follow James Newton-Brady, Consultant DBA who has been working with databases for over 15 years, and we discover what keeps him busy on a morning.
“A Consultant DBA’s day is never boring. The work is dynamic, and days are always different from each other. This is part of the job of being a consultant DBA, and it is also why it is so interesting.”
Lack of time and workload demands often get in the way of carrying out proper database housekeeping and, while the impact of these delays might not be immediately apparent, the end results might be very risky indeed.
Press enter to search or click the icon.
