Blueprinting Your Database Landscape
Crafting a map of your database servers can help you build better systems, from increased security to solid disaster-recovery plans.
by Steven Berringer
October 21, 2005
The scene is this: you are an Architect, Technical Manager, or DBA taking over an existing database group at a medium to large company. It would be surprising if someone handed you a 50-page document summarizing all aspects of this core Information Technology group: How many database servers are on the grid? Where are the backups going? What applications are using these database servers? What are the skill sets of the people in the group: You need the answers to all these questions and more, and this article will help you construct such a blueprint.
I have broken this guide into five sections: Inventory, Disaster Recovery, Security, Scalability, and Looking Ahead. There are a few critical items to look at immediately, so first you must ask yourself these questions: Are all the databases getting backed up, sent off site and restorable? Has someone tested each and every backup? Where is the sensitive data stored, and is it secure? (If Social Security numbers or credit card numbers are exposed, close that door as fast as possible.)
Although volumes could be written about each of these topics, I will cover these at a very high level. My goal is to give you a context in which to manage one of your corporation's most valuable assets: data.
Inventory
In a large company determining, how many RDBMS servers you have can be difficult. If you're lucky you have one data center and all the servers are sitting on a raised floor with their names printed on them. More likely you have a mainframe or two, some mid range mini computers, and multiple servers with a variety of operating systems spread throughout the world. Finding the mainframes and mini-computers should not be that difficult, but finding the desktop versions of Oracle, DB2, or SQL Server can be like an Easter egg hunt. The worst-case scenario is you're looking at production databases running from under someone's desk.
There are tools that can help you track down these "renegade" servers. SQL Server comes with a command-line tool named OSQL.exe that, when run with the –L option, will list out all the servers it can find. It will not report on 100 percent of them, but it's a start. With Oracle you are looking for the Listeners; check out http://www.petefinnigan.com/tools.htm for a list of free and commercial tools to help you identify and secure Oracle instances. A commercially available product from Application Security Inc is App Detective, which can find all the database servers on your network.
The goal is to create a list that gives you an overview of every database server. Here is a list of potential items that would be helpful for your roster:
Name: (name of the server)
RDBMS: (Oracle, DB2, SQL Server, MySQL, and so on)
RDBMS Version: (What version of the database engine is running?)
Operating System: (Windows, Linux, OS/390)
OS Version: (Windows 2003, Redhat 7.0)
Storage Fabric: (SAN, DASD, NAS)
Storage Capacity: 100 GB
Storage Free Space: 40GB
Location: Computer room in Cleveland
Production/Test/Development: Production
IT Owner: Jim Smith, Finance, IT
Sensitive Data: Yes
Mission Critical Data: Yes
Hardened: NO
Available From Internet: YES
Back to top
|