In most large data centers, the system or network manager is not the database administrator for the company database. The importance and complexity of corporate data generally requires that it have its own exclusive management team.
But even when you don't manage the database itself, data center personnel will most likely still manage the systems that run the database. This hardware still takes up space, uses power, and requires all the same support resources and activities as the other equipment in the data center.
Here is a list of management and operational issues that you should consider when adding such systems to your computing environment.
Almost any production database should justify its own dedicated server (or servers). If you try to share a system with other production functions, you risk bandwidth or file system conflicts. If you can keep normal user accounts off the system, you remove significant risk for failure or poor performance caused by processes unrelated to the database.
Even if you can share a server with other functions, as the database grows, the time will come when that no longer works. Separating functions later is much more complicated than setting them up separately from the start.
Space and resource requirements
Just like any other server in your data center, a database server has footprint (physical space), power, and cooling requirements. Database servers are nearly always good candidates to be connected to backup power or an uninterruptible power supply (UPS).
Your database may also require one or more redundant (mirrored) servers in case the main server fails. Be sure your space and resource requirements include these additional systems.
Depending on the type of corporate data being stored, limiting access to the database servers could be important. Systems housing customer data should be kept secure from anyone without a business need for access.
Limit physical access to the data center to those who genuinely require physical access to the equipment. Someone who can enter a data center has access to all the systems housed there, not just the ones for which they have some responsibility.
Limit user access to the database and the system running it to those who work with the data or manage the system. Allowing normal user access is asking for trouble. Even if no one does anything malicious, accidents happen. If possible, limit the places (either physical or via the network) from which the database server may be directly accessed.
If some users really need access to the database itself, put limits on the type of access whenever possible. If a user needs to search but not update, give that user read-only access. Application and Web site developers should always test their code on a non-production copy of a production database (one that could be recreated if necessary).
Network bandwidth and availability
Depending on the volume of data and the amount of user access, you may choose to separate the database server onto its own network segment to reduce the impact of network traffic on other systems. This is especially useful when you have a database spread across or mirrored on multiple servers where the servers are constantly communicating with each other to keep the different copies in sync.
If the data is used by a corporate web site that is outside the firewall, the database server may require its own firewall or special configuration to allow the web server access but still keep it protected from any other access.
Hardware and software maintenance
Like the other servers in your data center, your database servers will have regular maintenance needs and might suffer some type of hardware failure.
Be sure you keep your vendor hardware and software support up to date. Schedule downtime for upgrades or patches just as you would with any other system. Be sure you perform regular backups. Many databases provide their own methods for backing up the contents of the database. You should work with the database administrator to make sure your system backup includes all the data that would be required to recreate the database in case of a catastrophic failure.
If you have mirrored database servers, you can upgrade one while the other one is still providing access to the database. If you have to schedule downtime for an upgrade, be sure to take into account the accessibility requirements of the user community. If the database is required by a web site used by customers, those functions will be unavailable to your customers while the database is down.
If you have limited user access to the database server, then you won't have all the same user support issues that you have with most of your other systems. However, you will most likely support the database administrator.
Even if this person or group is not organizationally part of your team, you should foster as much of a cooperative relationship with them as possible. You all have the same goal: maintaining the reliability and availability of your corporate data.
King Ables earned his bachelor's degree in computer science from the University of Texas at Austin in 1982. He has been involved with Unix as a user, developer, systems administrator, consultant and author since 1979.