This week, we’ll wrap up our series on the aspects of database administration that need to be closely monitored.  In prior posts, we’ve highlighted the need to track and manage changes to database information, use of unapproved channels by privileged users, modification of database schemas, addition or alteration of user accounts, retrieval of data via unauthorized channels, access to live production systems, and unapproved changes to applications that access databases.

In our final entry, we’ll cover out-of-cycle patching of production systems, and why it so important to control such behaviors by database administrators and other users.

According to Gartner, “Most enterprises with robust operational management processes have defined ‘operational windows’ for patches.” For example, policy states that patches can only be applied on certain dates, or at certain times.  Patches that are implemented outside these windows, says the analyst firm, can cause serious problems with database storage and availability.

In a previous post, we discussed the importance of closely overseeing and approving each change made in the production environment.  Here, we’re talking about how to “force” adherence to that policy.  dbMaestro TeamWork™ requires each change to receive prior approval before it is implemented. And, when you combine TeamWork with other change management solutions designed to handle change requests or work items, such as IBM RTC or Microsoft TFS, you can manage the patching of production systems via a well-defined and closed-loop process. Each change will have to be approved by TeamWork, which means it must be correlated with a valid change request.  Without being linked to a CR, the change cannot be approved – and therefore, it cannot be deployed.

Additionally, using TeamWork in previous steps in this process, such as integration, testing, and changes made in the pre-production environment, can provide even greater visibility and control over the patching process.

Over the past few weeks, we’ve been discussing some of the many areas of database administration that analyst firm Gartner highlighted in a recent report about tracking and monitoring.  Topics we’ve already covered include changes to database information, use of unapproved channels by privileged users, modification of database schemas, addition or alteration of user accounts, retrieval of data via unauthorized channels, and access to live production systems.

In this post, we’ll talk about unapproved changes to databases themselves, or to the applications that access those databases.

Gartner believes that, “IT operations personnel have a strong tendency to want to fix problems as soon as they are recognized, without necessarily planning, testing or evaluating their ‘fixes’ or consulting the appropriate stakeholders. Auditors are continuing to focus on change and configuration management processes, especially within systems containing or processing regulated data.”

When databases are involved, Gartner adds, data security and availability issues can arise. The analyst firm urges that table structures, data types and other key database elements should not be changed unless those modifications are mapped against a change management system of some kind.

A lack of control over these types of changes can also lead to users making modifications directly to the production environment.  This can lead to many potential problems, such as application crashes because the code in the application does not match the code in the database, or a “backdoor” which can be inadvertently created, giving easy access to internal or external hackers.

That’s where dbMaestro TeamWork™ comes in.  Our cutting-edge database Oracle db change management environment forces the user making the modifications to perform check-out prior to executing the alterations.  Through seamless integration with a change request (CR) management tool, TeamWork can also directly link the check-out procedure to a valid change request.  If no such CR exists, the user will not be able to perform check out, and therefore, will not be able to make the change in the underlying Oracle database.  This will prevent unauthorized alterations from being made, and will preserve the performance of both the application, and the underlying database.

In prior posts, we discussed the importance of monitoring how database administrators (DBAs) and other super-users change database information, as well as their use of unapproved channels for database access.  This time around, we’ll cover the need to control how those privileged users modify database schemas.

The database schema “is central to its secure and efficient operation and management”, Gartner claims.  Therefore, “schemas and metadata must be kept absolutely consistent”, as incorrect or unapproved alterations could be detrimental to the performance of the database.  Without proper monitoring, privileged users could also inadvertently bypass monitoring or auditing mechanisms, creating tables or other objects containing mistakes and errors that can hinder – or halt – database operation.

Our powerful database version control solution, dbMaestro TeamWork™, eliminates these risks with a powerful locking mechanism that proactively prevents unauthorized schema modifications.  Since the DBA or other privileged user must perform check-out within the TeamWork environment, they will be unable to make changes that have not been audited or approved.  As a result, the integrity of database schemas is always protected and preserved.

Because TeamWork’s locking mechanism is tightly integrated into the database engine, it cannot be overridden.  Therefore, it will always track and audit schema modifications, regardless of the level of the user making them.

Another key feature of TeamWork is its ability to closely align database schema changes with software code changes.  This is particularly important as both schema and code modifications are often required as part of a specific application version.  With TeamWork, and its robust locking mechanism, schema modifications that create conflicts or problems with code can be avoided.