Not thinking only about databases, but in general, efficient management of an IT environment is truly a challenging task. Given the complexity of assets to be controlled, resources to be managed, in addition to the diversity of environments, programming languages, database administration, and connectivity solutions.
The IT manager is always concerned with having an environment where they can achieve maximum control or predictability, whether for incidents, problems, or even changes resulting from asset replacement. There may also be a software update, ranging from a server’s operating system to versions of programs updated by the software vendor used in the company.
One of the most important environments to be managed is often neglected: the databases in use. DBMSs, or Database Management Systems, are a reality in virtually all IT environments, whether in small, medium, or large companies.
Having a Service Desk solution that can effectively manage the IT environment, including databases, anticipating problems and incidents is the goal of every IT manager. This will allow them more time to dedicate to improvements to be implemented, as well as to align with the company’s business and be an active partner in top management projects.
Poorly designed databases can be responsible for service unavailability issues, low performance, and, in more extreme cases, data loss. This becomes catastrophic in business terms and, eventually, in business continuity, since companies have already closed their doors upon losing their entire financial, accounting history, and customer portfolio due to data loss. Therefore, we have listed below:
The main mistakes to avoid in database management:
1. Not having a backup policy
This is, first and foremost, the biggest concern we must have: a defined and documented database backup policy. It must address backup routines, storage media, retention policy, and data restoration techniques.
Many business models may allow system unavailability for minutes or hours with little financial loss, but completely losing data is inadmissible, especially when business value nowadays lies in information.
The retention policy will dictate how long data must be kept. This will depend on the type of business and what is agreed upon between management and IT.
2. Providing unlicensed products
The use of unlicensed software can be a major problem when it comes to having or not having vendor support to resolve system bugs or apply fixes (known as patches).
Some versions of commercial products have free options, but with limited features. They usually moderate the number of processors used, amount of memory, or maximum database size.
When defining the database solution, it is essential to keep in mind the possibility of needing to contact the manufacturer to resolve any software defects.
3. Poorly sizing resources
A database system requires the work of a specialist to dimension the resources to be used, as well as tuning — database refinement. Default installations will not work in a real environment in the vast majority of cases.
Some items that need to be analyzed and properly sized are:
- Configuration of the amount of memory to be used by the database;
- Number of processors;
- Disk size;
- Number of concurrent sessions that can be opened;
- Refinement of the operating system of the server hosting the DBMS.
Omitting this part runs the risk of having a system that constantly goes down while the IT team tries every possible way to find the cause of the constant crashes.
Bonus: Complete guide to implementing a Service Desk in your company
4. Maintaining outdated versions
Generally, a DBMS vendor allows the basic version to be installed for testing. Depending on the solution, it is necessary to apply patch fixes, which resolve issues ranging from incompatibility with certain operating system features to fixes in the database language itself.
These patches usually resolve stability issues or abnormal application behavior. However, in many cases, systems run on top of the pure version without fixes, which represents risks of crashes and system errors.
5. Not monitoring the environment
A database system tends to grow over time, as it naturally stores accumulated information. This requires a storage policy and, consequently, a monitoring system that tracks the growth of the database.
In addition, CPU consumption, memory usage, query response time, and other metrics must be monitored to ensure that the server is operating at full capacity.
6. Not investing in security
A database server, as we have realized, is a very sensitive and strategic asset. Hence, access to it must be restricted only to people with proper credentials, such as database administrators, system administrators, and others defined by the company’s security policy.
The use of secure and non-public passwords is a basic security requirement to prevent someone from deciding to restart the server in the middle of the day, for example. Data access, in turn, is defined by business rules through the applications that use the database.
At this point, security is implemented by company rules, which should also have an audit policy for actions performed. This policy must record logins, station IP, modification date, and records of altered data.
[cta id=’13767′]
7. Allowing a lack of redundancy
We can have backups, security policies, and many preventive actions. However, if our database is of the standalone type — a single instance —, we are subject to unavailability every time there is an issue or even when the service needs to be restarted due to patching, updates, or a scheduled reboot.
An environment known as a cluster, with at least two nodes, ensures system availability. When one server goes offline, the other takes over and responds to requests.
Ultimately, having a monitored database system will guarantee a stable, robust environment with a minimum of unavailability incidents. If you liked the article, leave your comment.
