Blog Host: Craig Mullins, Years 2005-2006 READ ENTIRE BIO

One overarching trend in the database industry is rapid DBMS versioning. It seems like we just start to get a handle on the latest and greatest version of our favorite DBMS and then -- wham! -- the vendor releases a new version. I mean, people are still digesting Oracle9i and then Oracle unleashes 10g on the world. And how about IBM? On the mainframe side of the world most folks are still using DB2 V7, even though V8 has been available since March 2004. Who wants to be the first to encounter all those bugs that you just know are in that new version? So, most people wait until the bleeding edge implementers have slogged through the upgrade until starting to plan their upgrade path. That means we have two or three versions that are considered "current" (at least by the users) in the field. In such situations it becomes very difficult to keep up with which features are available and which are not.

Which leads me to the next big trend: complexity. Our database systems are getting more and more complex. This trend is driven by all of the new features and functionality in the new versions, along with the fact that most organizations have heterogeneous database implementations. Let's tackle feature bloat first. Today's modern DBMS offers functionality never dreamed of by the database pioneers of the 1970s. The DBMS is sucking features into it that previously required you to purchase additional software. For example, today's DBMS products usually offer analytical/OLAP and ETL features. In the 1990s these were common products, but today they are common features. So the DBMS becomes more complex. Additionally, we add new data types (BLOBs, CLOBs and so on), code (UDFs, triggers, stored procedures) and XML support. These make the DBMS of today more functional and, yes, much more complex.

Heterogeneity is an issue, too. Most organizations have multiple DBMS products installed and managing corporate data. Rare is the shop that only has to worry about Oracle or DB2 or SQL Server. Instead, they have all three and maybe MySQL and IDMS, too. Now how do you ensure data integrity when the same data is spread across each of these products? And maybe in Access and Excel, too?

Another consistent trend is the on-going Web enablement of our data. And the DBMS is changing to better support this trend. So, too, are DBAs changing. The biggest challenge for Web-enabled data is availability. If data is not available, the e-business is not functioning. This will impact sales, profitability and ultimately stock price and valuation. Being prepared to eliminate and reduce planned and unplanned outages is the biggest job of the eDBA. This requires more automation and better tools, as well as forethought, planning and vigilance. A modern DBMS allows more changes to be made without requiring the database to be brought down. Furthermore, the modern Web-enabled DBMS supports Java, .NET, XML and other Web technologies. It is better integrated to Web servers and application servers. And it is supported by tools that enhance availability by enabling on-the-go maintenance tasks.

Another trend is industry consolidation. This one has started to hit the DBMS market with IBM acquiring Informix (a few years ago) and Oracle acquiring PeopleSoft just a couple months ago. This trend is actually industry-wide and is likely to continue. The smaller DBMS vendors may get swallowed up by the larger ones. And as when DBMS vendors acquire application vendors, we all get to sit and wait to see how well competing DBMS products are supported. I mean, does anyone really believe that Oracle will still be supporting DB2 and SQLServer in the PeopleSoft/Oracle applications five years from now? Maybe, but, then again, maybe not.

Of course, many other trends exist in the industry that impact the database market, including open source, data growth, ERP, CRM, data warehousing and business intelligence, outsourcing and so on. The only way to stay on top of things is to allot time to study, learn and research. Good luck keeping your databases up and running!
Posted by Craig Mullins A database bookshelf
09 FEB 2005 06:26 EST (11:26, GMT)
Achieving success working with a database system can be a difficult task. In order to prosper you must have an inquisitive mind and an ongoing desire to learn. In this day and age of frugality and meager training budgets, much of your education will be self-taught. One of the most cost-effective ways to learn something new is still by reading books. Fortunately, there is no shortage of excellent material for database professionals to choose from. In today's blog I will recommend some of my favorite database books.

There sure are a lot of books out there written about database management systems. Most of them are useful, but which ones are indispensable? I'm sure that question is debatable, but I'm going to give you my opinion.

First of all, let's set some limits. I am not going to recommend any books that cover only a single DBMS -- so no books that cover just DB2 or only Oracle. There are quite a few good ones out there like that, and I even wrote one for DB2. Secondly, I will not talk about any book that is out of print or difficult to obtain. No one wants to pay over $100 for a rare database book anyway, so why talk about such books…?

Also, I won't hype my own books -- oh, well, if you must know, I do recommend my Database Administration book, but I won't try to hard sell you on it. I really want to share with you some of my favorite database books. First of all, let's talk about some good SQL books.

Every professional programmer (and DBA) should have a good book or two on SQL. There are many to choose from, and a lot of them are very good. I have two to recommend that I think are outstanding. The first SQL book is SQL Performance Tuning by Peter Gulutzan and Trudy Pelzer. It provides a treasure trove of tips for improving SQL performance on all of the major DBMSs. This book does not teach SQL syntax, but instead helps the reader to understand the differences between eight DBMSs, including Oracle, DB2, SQL Server, Sybase ASE, MySQL, Informix, Ingres and even InterBase. Throughout this book the authors present and test techniques for improving SQL performance and grade the technique for its usefulness on each of the major DBMSs. If you deal with heterogeneous database implementations, this book will be of great assistance, whether you are a programmer, consultant, DBA or technical end user. The contents of this book can help you to decide which tuning techniques will work for which DBMS.

My next SQL book recommendation is altogether different in purpose than the first. It is SQL in a Nutshell, 2nd edition by Kevin Kline, Daniel Kline and Brand Hunt. This book offers a great cross-platform syntax reference for SQL. It probably is not the easiest reference to use for finding the exact syntax for one particular DBMS, but it is absolutely the best reference for those who work with multiple DBMSs. Be sure to get the second edition, which is more up to date and offers more depth than the skinny first edition.

Another excellent book that I highly recommend is Joe Celko's SQL for Smarties. This is a book that delivers on its title. Joe offers a plethora of useful SQL coding techniques that might take years to assemble if you go it alone. The current edition is a little dated (published in 1999), but it still contains enough useful nuggets to make it a worthwhile investment. And never fear -- Joe is hard at work updating his book and a new edition will be available soon.

An Introduction to Database Systems, 8th Edition by Chris Date belongs on every database professional's bookshelf. This book is expensive, but worth every penny of its price. It will not teach you how to use existing commercial DBMS products, but it is the best book on the market for teaching the fundamental of database management.

Finally, it is a good idea to have a nice reference on database design and data modeling. There are a lot of books on this topic, too, but one of my favorites is Data Modeling Essentials, 3rd edition by Graeme Simsion and Graham C. Witt. This book provides a good, solid tutorial on data modeling from two of the foremost experts on the topic. It is useful for all levels (beginner to expert) of data modeling expertise.
Posted by Craig Mullins It's alive! It's alive!
09 FEB 2005 06:16 EST (11:16, GMT)
There is a lingering perception in some parts of the IT industry that the mainframe is dead. Nothing could be further from the truth. The market for mainframes and mainframe computing is healthy and, indeed, continues to grow.

The client/server bandwagon that swept through the IT world in the late 1980s and early 1990s threatened the existence of the mainframe. Pundits everywhere declared mainframes old technology and no longer relevant. But organizations quickly learned that the scalability, performance and reliability of large-scale mainframes was hard to duplicate. Today, most large organizations still rely on mainframe-class computers like IBM's zSeries systems for much of their mission-critical computing needs. The mainframe was not banished, but is a vital component of the overall IT infrastructure of most large corporations.

The Year 2000 (Y2K) problem was perhaps a bigger threat to the mainframe than client/server. Given the mainframe's long history and heritage, the predominance of Y2K code problems existed in mainframe applications. Users, in some cases, replaced those systems with new applications that run on different, client/server machines. But only infrequently did shops swap out their mainframe wholesale for a completely new computing platform. If the Y2K problem did not provide the push to do this, what will?

Mainframes have been around for a long time. As such, the glass house that was erected to provide the care and feeding of mainframes has proven to be one of the primary benefits of mainframe computing. Most IT shops are looking to improve manageability and availability. The mainframe excels at these tasks not only because of the support infrastructure built around them, but because of the years spent by vendors such as IBM improving the quality and functionality of the hardware.

The mainframe of today is quite different from the mainframe of yesteryear. That hulking, water-cooled beast you may remember has been replaced with chip-based, CMOS, air-cooled systems. And today's mainframes are easier to hook together using parallel Sysplex technology. In short, the word "mainframe" need not mean unfriendly green screens, complex JCL and ancient COBOL programmers any more. By adapting its technology when threatened by a new client/server paradigm, the mainframe has not just survived, but improved upon itself and thrived.

Perhaps the biggest "problem" that today's mainframe systems face is one of "word of mouth." So much has been written and implied about the mainframe being dead that a lot folks believe that hogwash. Few organizations that rely on mainframes to run their complex information processing tasks would even consider thinking about replacing them. And if they consider it, the cost of conversion coupled with the reduced availability and scalability of alternate solutions quickly brings them back to their senses. The mainframe continues to be a robust, viable component of today's IT infrastructure. Organizations continue to add more MIPS, deploy more applications and run their most important, mission-critical applications on mainframe computers.

According to an article in Information Week, more than 75% of internal data accessed by corporate PC users is stored on mainframes. Additionally, more than 60% of all data available over the Web originates from mainframe databases, and over 80% of all commercial transactions are processed by mainframes.

The mainframe is a robust, reliable and heavily utilized platform.

The reports of its death were greatly exaggerated.
Posted by Craig Mullins DBA certification
08 FEB 2005 00:00 EST (05:00, GMT)
Professional certification is a popular trend in IT and is available for many different IT jobs. The availability and levels of certification have been growing at an alarming rate for database administration. Certification programs are available for most of the popular DBMS platforms including IBM DB2, Microsoft SQL Server and Oracle. The concept behind DBA certification is to certify that an individual is capable of performing database administration tasks and duties.

This is a noble goal, but the problem is that passing a test is not a viable indicator of being able to perform a complex job like database administration. Some things you just have to learn by doing. Now, I am not saying that certification is useless. Indeed, taking the test and focusing on the questions you miss can help to point out areas of weakness upon which you can improve. But does anyone really believe that someone passing a formalized test will be as capable as someone with several years of experience as a DBA? Organizations should hire DBAs based on past experience that indicates a level of capability. Of course, someone with both experience and certification is better than someone with only one of the two.

I do recommend that professional DBAs take the time to study and pass the certification exams. Not because certification will make you a better DBA, but because it will make you more employable. Some companies will hire only certified professionals. The trend toward using certification to guide hiring practices will increase because of increasing IT complexity. If you think you might change jobs at some point in your career (and who among us will not), then certification is a worthwhile pursuit.

Keep in mind that the DBA certification tests sometimes ask arcane syntax questions that are not really good indicators of a DBA's skills. Getting the syntax 100% accurate is what manuals and design tools are for. There is no reason to memorize syntax because it tends to change quite often. It is better to know where to find the syntax, parameters and answers to your questions when you need them; that is, which manuals and textbooks contain the needed information. DBAs should possess a broad over-arching knowledge of DBMS concepts, IT fundamentals and a good knowledge of the way in which their organization's database systems work. Memorizing every detail about SQL syntax and structure is a waste of time because it is complex and changes all the time. In other words, it is better to know off the top of your head that something can (or cannot) be done than to know the exact syntax for how to accomplish it.

If you decide to pursue certification, take the time to prepare for the tests. There are books and self-learning software titles available that can be quite useful. These books and programs cover the most likely test topics and provide sample questions to help you prepare. In many ways it is like preparing for a college entrance exam, like the SATs.

And one you earn your certification, make sure you display it proudly on your resume and your business card (if your company allows it).

The following Web sites contain information about professional certification for the most popular DBMS products.

DBMS	Web site with certification information
Oracle	http://www.oracle.com/education/certification/index.html
Microsoft SQL Server	http://www.microsoft.com/learning/default.asp
IBM DB2	http://www.ibm.com/certify
Sybase Adapative Server	http://www.sybase.com/education/profcert/

Posted by Craig Mullins How many DBAs?
07 FEB 2005 06:16 EST (11:16, GMT)
One of the common problems that perplexes DBA groups is how many DBAs are needed to support their environment. One thing is for sure: It is always more than are currently there (from the DBA's point of view), but the management perspective is usually that there are just enough (or even worse, too many already).

Staffing the DBA organization is not a simple matter. There are several non-trivial considerations that must be addressed including the size of the DBA staff and the reporting structure for the DBAs. In my book, Database Administration: The Complete Guide to Practices and Procedures, I discuss the issues that impact DBA staffing levels.

Basically, it boils down to complexity. The more complex your environment, the more DBAs you will need to assure availability, ensure data integrity, optimize performance and basically keep your database systems and applications operational. Of course, it is very difficult to combine all of the mitigating factors into a specific formula that will dictate the optimum number of DBAs to employ.

Some industry analysts have tried. A few years ago analysts at META Group published a loose formula for calculating DBA level of effort. Their formula applied weights to six factors: system complexity, application immaturity, end-user sophistication, software functionality, system availability and staff sophistication. By measuring each of these items as much as possible to indicate high or low rates, you can plug in values to the formula and arrive at a a number that is tranlated into an estimate for the number of DBAs required. Of course, this research is dated and META Group has since been acquired by Gartner Group.

I've heard of DBA groups who use a simple formula like 1 DBA per 10 database instances. But how useful is that, really? A very experienced DBA could easily handle double that if the activity is low and the systems are well tuned. But if activity is high, the databases are not well designed or SQL is coded inefficiently, that DBA might be stretched to his (or her) limits. You just can't put a simple formula on top of a complex problem.

I guess the bottom line of this blog entry is to just ruminate on the difficulty of the problem. And to ask what guidelines (if any) your organization follows to arrive at the correct number of DBAs to manage your company databases. Let me know.
Posted by Craig Mullins On becoming a DBA
04 FEB 2005 05:45 EST (10:45, GMT)
One of the most common questions I am asked is: How can I become a DBA? The answer, of course, depends a lot on what you are currently doing. Programmers who have developed applications using a database system are usually best-suited to becoming a DBA. They already know some of the trials and tribulations that can occur when accessing a database.

If you are a programmer and you want to become a DBA, you should ask yourself some hard questions before you pursue that path. First of all, are you willing to work additional, sometimes crazy, hours? Yes, I know that many programmers work more than 40 hours already, but the requirements of the DBA job can push people to their limits. It is not uncommon for DBAs to work late into the evening and on weekends; and you better be ready to handle technical calls at 2:00 a.m. when database applications fail.

Additionally, you need to ask yourself if you are insatiably curious. A good DBA must become a jack-of-all-trades. DBAs are expected to know everything about everything -- at least in terms of how it works with databases. From technical and business jargon to the latest management and technology fads, the DBA is expected to be "in the know." And do not expect any private time: A DBA must be prepared for interruptions at any time to answer any type of question -- and not just about databases, either.

And how are your people skills? The DBA, often respected as a database guru, is just as frequently criticized as a curmudgeon with vast technical knowledge but limited people skills. Just about every database programmer has his or her favorite DBA story. You know, those anecdotes that begin with "I had a problem..." and end with "and then he told me to stop bothering him and read the manual." DBAs simply do not have a "warm and fuzzy" image. However, this perception probably has more to do with the nature and scope of the job than with anything else. The DBMS spans the enterprise, effectively placing the DBA on call for the applications of the entire organization. As such, you will interact with many different people and take on many different roles. To be successful, you will need an easy-going and somewhat amiable manner.

Finally, you should ask yourself how adaptable you are. A day in the life of a DBA is usually quite hectic. The DBA maintains production and test environments, monitors active application development projects, attends strategy and design meetings, selects and evaluates new products and connects legacy systems to the Web. And, of course: Joe in Accounting just resubmitted that query from hell that's bringing the system to a halt. Can you do something about that? All of this can occur within a single workday. You must be able to embrace the chaos to succeed as a DBA.

Of course, you need to be organized and capable of succinct planning, too. Being able to plan for changes and implement new functionality is a key component of database administration. And although this may seem to clash with the need to be flexible and adaptable, it doesn't really. Not once you get used to it.

So, if you want to become a DBA you should already have some experience with the DBMS, be willing to work long and crazy hours, have excellent communication and people skills, be adaptable and excel at organization. If that sounds like fun, you'll probably make a good DBA.
Posted by Craig Mullins Open source database systems
03 FEB 2005 06:14 EST (11:14, GMT)
Open source is a rolling freight train that cannot be stopped, as much as Microsoft may want to stop it. LAMP architectures will be used for certain database applications and systems that meet a specific set of criteria. LAMP stands for Linux, Apache Web server, MySQL database and the PHP/Python/Perl development languages. It is a collective of open source software that can be used to deploy applications with minimal cost, which is the intriguing part to most of its adopters.

The "no cost" aspect of open source and LAMP is both a positive and a negative. It is positive for the obvious reasons; I mean, no one wants to spend money for something if they can avoid it, right? Of course, the "no cost" label only applies to the initial acquisition cost of the software, and then only maybe. Red Hat, MySQL and others sell distributions of the software to make implementation and management easier. Additionally, support is crucial. Do you really want to implement a mission-critical application on free LAMP software and then not have anyone to turn to if problems occur? In other words, who will support the software when you have issues? Companies exist that sell this support. But now if we are buying the software and support to go along with it, how much different is it than commercial software?

At any rate, open source and LAMP will succeed for those projects that could not be cost-justified or are not affordable with commercial OS/DBMS/Web server software. As the projects gain acceptance in the company, additional support can be purchased to ensure the viability of the applications.

But would I predict that a major insurance company, for example, would implement its policy and customer system on "open source"/LAMP technologies? Nope. Never. That is not the "sweet spot" for open source. So, will open source databases ever become popular enough to strongly compete against Microsoft, Oracle and IBM for the database consumer's dollar? I don't think so. Open source DBMS software will be used in conjunction with the major enterprise DBMSs and in SMBs that cannot cost-justify an enterprise DBMS.

Interestingly, I think open source database technology will face some problems in the near-term future. The major open source DBMS products (MySQL, Firebird, PostgreSQL and Sleepycat) are mostly simpler to use than enterprise DBMS products because they do not have all the bells and whistles of the enterprise software. Over time, these are being added to the open source players. Triggers, stored procedures, integrity constraints and so on will make the open source DBMS products more complex to use, and, therefore, smaller organizations will have more difficulty deploying them rapidly. The software may be moving away from its sweet spot in terms of how and when it is implemented.

An interesting twist to the open source DBMS issue is the recent entry of Computer Associates to the game. In May 2004 CA announced that the release of its Ingres relational DBMS product into the open source community. Ingres was released under the CA Trusted Open Source License (CA-TOSL). Under the CA-TOSL, independent software vendors can incorporate Ingres into their products as long as the Ingres source code is provided with the product. CA will offer support and indemnification as added-cost options to the CA-TOSL Ingres. The Ingres source code is available here.

This move by CA gives open source developers another database option. This is good news for developers, but the open source DBMS market is already somewhat crowded with MySQL, PostgreSQL, Firebird and Sleepycat Berkeley DB. Furthermore, PostgreSQL grew out of the original Ingres DBMS, so now we have both Ingres and PostgreSQL available as open source software. Perhaps the growing acceptance of open source (and PostgreSQL) in the market place helped to force CA's hand in turning over Ingres to the open source community.

The bottom line is that there is a wealth of options if you are interested in using an open source DBMS product. But know what your needs are and what features are available in the open source DBMS products before diving headfirst into the open source waters.
Posted by Craig Mullins Self-managing database systems
02 FEB 2005 05:45 EST (10:45, GMT)
One of the more insidious tales being spread these days is that there are database systems that are capable of managing themselves. For an enterprise database implementation, this is a big fat lie. Oh, yes, the DBMS vendors are doing a nice job of making their systems more manageable -- and they are to be commended for that. I take task only with the exaggerated statement that these improvements render database administration unneeded for their database implementations.

IBM, for example, has announced some interesting autonomic features for DB2. The DB2 optimizer has had "query rewrite" technology for some time now. But does any DB2 DBA out there believe that queries no longer need tuning? Other features that enable online schema changes, online system parameter changes and automatic refresh and query re-write with materialized query tables are great features. But they do not warrant the description "self-managing."

Many data management tasks will always require the guiding hand of a DBA. Making changes to database structures, for example, will not be something that the DBMS could ever understand or be able to do without human involvement. A DBA will still need to direct this type of work. And what about recovery? How can a database system that is down recover itself? If it was so self-healing to begin with, why did it go down in the first place? No, we'll always need DBAs to be there to help recover from system failures, at least.

Additionally, many times the self-managing features of the DBMS require the user to purchase a separate product. But DBAs are already aided by automation and self-healing technology provided by the tool vendors. The DBMS vendors are just now starting to offer some of these types of DBA tools, and they market them as "autonomic" or "self-healing" to generate buzz. But it is nothing new. DBAs can use database tools from many different vendors today. Some are powered by intelligent automation -- meaning the tools make complex tasks easier to accomplish with built-in knowledge of the environment. Just because the DBMS vendors are starting to offer such tools does not make the DBMS somehow magically self-managing.

Furthermore, DBMS tools will not supplant ISV tool vendors either. An independent ISV can monitor and manage heterogeneous database implementations. Can you imagine IBM ever helping you to manage Oracle? Or Oracle helping you to monitor SQL Server? Not gonna happen!

Additionally, ISV tools can offer DBAs control they might lose when DBMS vendors move previously configurable options into wizards and self-configuration tools. Many times the DBMS vendor removes or hides configurable options to simplify administration and to prevent novice DBAs from making hit-or-miss changes that result in disaster. The ISVs keep these options visible and configurable -- the way they need to be to effectively manage significant database implementations.

So, although it is possible to intelligently automate many DBA tasks, we will still need a flesh-and-blood DBA to keep on top of the DBMS.
Posted by Craig Mullins The data explosion
01 FEB 2005 05:34 EST (10:34, GMT)
Businesses today are gathering and storing more data than ever before. We are said to be living in the "information age," and data is the capital of the new economy. With this explosion in the amount of data being stored, organizations are relying more than ever on database management systems to get a handle on corporate data and extract useful business information from that raw data.

I visit a lot of different organizations each year as a part of my job, and one thing is consistent: Databases are growing in size. I've never had a DBA say to me, "You know, my databases are getting smaller, and I just can't handle it." Nope, it is always just the opposite. Organizations everywhere are struggling with the burgeoning size of their corporate databases.

Winter Corp., a research and consulting firm, publishes a semi-annual survey of the largest and most heavily used databases in the world called the Top Ten Program (more details here). The most recent Winter report, published in 2003, confirms this explosion of data. Winter reports the largest data warehouse implementation grew to almost 30 TB, and the largest operational database contained just under 20 TB of data. And those are just the largest. The average size of an OLTP database grew from 1 TB in 2001 to 4.4 TB in 2003.

More data is a fact of life for today's businesses, and, as such, corporate databases are growing in size. Indeed, technology usage is growing and becoming more complex, but the rate of data growth has exploded. There are several factors driving this growth.

Data warehousing and data mining applications encourage us to store more data for longer periods of time. The analytical insight offered by such implementations far outweighs their cost. Web applications can increase data growth as well. Monitoring the clickstream requires the storage of more and different types of data than were previously needed. Multimedia data also increases storage requirements. As we move to store and manage not just numbers and text, but also video, audio, images, temporal data and more, data growth will continue unabated.

Most organizations today deploy multiple, heterogeneous computer systems -- from large mainframes to midranges to workgroup networks to PCs. And the same data may exist on all of these different platforms. Organizations are copying data several times to multiple platforms and DBMS products, data that used to exist on a single centralized system. So heterogeneity causes data growth.

Nascent technologies, such as RFID tags, will further add to the deluge of data that must be maintained and accessible. Indeed, the need for database systems will continue far into the future, as will the need for DBAs to manage those databases.
Posted by Craig Mullins The morphing of database administration
31 JAN 2005 06:25 EST (11:25, GMT)
I'd like to welcome you to my new blog on the topic of database administration and modern database systems. I'm looking forward to using this opportunity to discuss some of the trends and issues impacting data management professionals circa 2005.

One of the biggest changes I see these days is the ongoing redefinition of the job roles and responsibilities of database administrators (DBAs). Oh, most people know the rudimentary aspects of the job, namely keeping your organization's databases and applications running up to par. The DBA has to be the resident DBMS expert (whether that is DB2, Oracle or SQL Server, or most likely a combination of those). He or she has to be able to solve thorny performance problems, ensure backups are taken, recover and restore data when problems occur, make operational changes to database structures and, really, be able to tackle any issue that arises that is data-related.

All of these roles continue to be requirements of the job, but that is no longer sufficient for most organizations. The DBA is expected to take on numerous additional -- mostly technical -- roles. These can include application development, managing the application server, enterprise application integration, managing Web services, network administration and more.

Indeed, I would guess that if you compare the job description of DBAs across several organizations, no two of them would match exactly. This is both good and bad. It is good because it continually challenges the technically minded employees who tend to become DBAs. But it can be bad, too; because the job differs so much from company to company, it becomes more difficult to replace a DBA who leaves or retires. And no one can deny that database administration is a full-time, stressful job all on its own. But the stress level just keeps increasing as additional duties get tacked onto the DBA's "to do" list.

Over the course of the next couple weeks I will examine issues like these, as well as other data-related topics. Drop me a line if you have a favorite topic you'd like to share with me. I'd be happy to hear from all of you.
Posted by Craig Mullins