|
|
News, views, and issues involved in managing data as a valuable corporate asset.
-
One of the questions I get on a regular basis is some variation of "how can I choose what DBMS is the best"... so I'll try to offer some high-level guidance for posterity here in my blog. This is actually a very interesting question, but the problem and the answers to it take on many different forms. For example, should I answer it based on you having no existing DBMS and you're just looking to buy one for the first time? That is a valid, though not too common, situation. On the other hand, you are more likely asking something like "Which of the several different DBMS platforms that we already have should we use for Project X?" This is also a valid question. So, let me try to answer both -- at least in some fashion.
First of all, if you are brand new to DBMS it would be a very wise course of action to hire a database consultant (or two) to help you with your selection process.Yes, consultants with specialized DBMS knowledge can be expensive, but not as expensive as purchasing or selecting an inappropriate DBMS for your project. A couple of days to a week of a consultant's time will be money well-spent if you do not have the internal expertise to make an informed decision on a DBMS platform. But you came here to read my thoughts on this topic, so I will not just tell you to hire a consultant and not give my opinions! So what do I think about this topic?
Well, there are several very good choices out there. My preference is that new users should generally choose from the market leaders, and that means one of the big three: IBM DB2, Oracle, or Microsoft SQL Server. Of course, you also have other options such as an open source DBMS like MySQL or PostgreSQL. These are up-and-coming platforms and they can be used for some types of production work (mostly lower-end or simpler web-based development projects). For high-end mission-critical applications, stick with the Big Three.
OK, which of the big three? Well, if you work for a large organization with a mainframe and want to run your DBMS on that mainframe, you really should go with IBM DB2. Oracle has a mainframe version of their database server, but IBM is far and away the market leader here. Other mainframe DBMS choices are legacy hierarchical (IMS) or CODASYL (IDMS) system. For Unix and Linux installations, your choices are Oracle and DB2. Oracle is the market leader on those platforms, though IBM has a nice presence there, too. For Windows development, all three are viable options, but Microsoft (as might be expected) is the leader on Microsoft's OS.
What about other options? Well, Sybase, Informix, and Teradata are the next biggest players in the market. Sybase has lost ground in the market, but their DBMS is still solid and they are firmly entrenched in many financial institutions. Informix, which was purchased by IBM, is still being maintained and marketed, but DB2 is obviously IBM's primary DBMS – so I personally would not choose it for new work. Teradata is a high-speed DBMS that is geared for data warehousing and OLAP work -- and you might want to choose it for those types of projects. Still, though, my primary advice holds: stick with one of the Big Three as much as possible.
OK, so what if you have several DBMSs installed and need to choose between them for a new project? In that case, it is best to base your decision on internal company issues. Consider the existing support and expertise that you have in-house for each DBMS. If the project is highly visible it makes sense to go with the DBMS that is best supported by your in-house experts because they can give it the care and feeding it needs to perform optimally. Also, think about the hardware platform. For your very high availability needs go with the mainframe if you have one. After that, it is Linux and Unix... then Windows. I haven't talked about cost yet, but it would be an incomplete answer without at least touching on that subject. When you are examining the cost of the DBMS software do not limit the analysis to just the initial cost and on-going maintenance cost that must be paid to the DBMS vendor. Look at the total cost of ownership of the DBMS. TCO should be calculated as a combination of the license cost of the DBMS, the license cost of any required supporting software (and hardware), the cost of database professionals to program, support and administer the DBMS, and the cost of the computing resources required to operate the DBMS. Also, try to factor in the reliability of the total package in terms of downtime - and factor in expected losses due to downtime if at all possible.
Determining the TCO for a DBMS can be difficult, and in many cases these type of decisions boil down to subjective opinions. Which DBMS is the favorite of the manager in charge? Or which one has s/he had experience with in the past? Whenever possible try to remove the emotional portion of the decision from the process. Reason, research, and analysis trump emotion every time...
|
-
Have you ever read those inserts that your bank, your credit card companies, your insurance company, your mutual fund company, and others slip inside your statements and bills? We all get them. Those inserts in our bills and financial statements printed in small type and written in convoluted English. I have started collecting them – sort of like baseball cards. But I doubt they’ll ever be valuable. They are entertaining, though. And disheartening. You really should read them. There are all sorts of interesting phrases and sentences written on those little pieces of paper. Now some companies are a lot better than others in terms of what their privacy policy promises, but if you read just about any of these little documents you'll likely find something to trouble your tormented soul. One thing you’ll see in just about every one of these little documents is the phrase “…unless otherwise permitted by law.” So, basically they are telling us this: “We’ll do what we say here unless we can find some law that allows us not to.” Oh great! I guess we all have to read every law on the books before we can trust this policy. I’d feel a lot better if the document had the phrase “…unless otherwise forbidden by law” in it. That way we could (hopefully) feel confident trusting the policy to be as strong as what is actually written there, if not moreso. As it is, we should feel confident that the policy is not anywhere near as strong as what is actually written there until it is proven otherwise. I guess I’m a pessimist, but I think I’m actually more of a realist given the sad state of data security and protection these days. Hopefully the above statement refers to the more useful and explicit information found in another privacy policy: “For example, federal law permits us to share information about you with consumer reporting agencies, service providers and financial institutions with which we have joint marketing agreements.” At least this company tries to explain their intentions instead of just appending “…unless otherwise permitted by law” all over the place. Here is another line that I despise from yet a another privacy policy: “When required by law, we will ask your permission before we share your information for this type of marketing.” The type of marketing referenced here is with “nonaffiliated service providers and joint marketing programs.” So, this policy is basically saying that this company will take your information and share it with anyone they want unless the law forbids it. Oh, it does say that they require the folks they share the data with to “keep our investor information confidential and secure and to use it only as authorized by us.” But I wonder how strict this requirement is? And what is the stated privacy policy of these partners?
Here is a classic taken verbatim right out of the privacy policy of a large bank: “Even if you do tell us not to share, we may share other types of information within our family.” So, why should I even waste my time trying to stop you? If this company were honest they would change the name of this policy to the “lack of privacy policy,” because that is what it is. A better privacy policy would protect their customer’s information much better. If there are specific things that will always be shared these should be explicitly stated and referenced. And it should be clear what is meant.
It is interesting to compare the privacy policies for the same company as (if) they change each year. One trend seems to be the addition of Chief Privacy Officers. This could be a good trend. But I bet the Chief Privacy Officer is more concerned with furthering the interests of the company s/he works for than actually protecting the privacy of the company’s customers. But maybe I’m being a pessimist again? The bottom line is that privacy is evaporating. We should try to do as much as we can to stop that evaporation. So should the companies that we do business with. And so should DBAs and data management professionals who deal with corporate data on a daily basis.
|
-
Every professional programmer (and DBA) should have a good book (or four) on SQL. There are many to choose from, and a lot of them are very good.
The first SQL book I recommend 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 database systems. This book does not teach SQL syntax, but instead helps the reader to understand the differences between the most popular DBMS products, 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 each technique for its usefulness on each of the major DBMSs. If you deal with heterogeneous database implementations this book will be a 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, 3rd edition by Kevin Kline, Daniel Kline, and Brand Hunt. This book offers a great cross-platform syntax reference for SQL. It may not be the easiest reference to use for finding the exact syntax for one particular brand of DBMS; but it is absolutely the best reference for those who work with multiple DBMSs. Be sure to get the 3rd edition, which is brand new
as of December 2008. It is more up-to-date and offers more depth than the previous editions.
Next up is The Art of SQL by Stephane Faroult, which is a guide to SQL written using the approach of "The Art of War" by Sun-Tzu. The author actually uses the exact same title chapters for The Art of SQL that Sun Tzu used in The Art of War. Amazingly enough, the tactic works. Consider, for example, the chapter titled "Laying Plans," in which Faroult examines how to design databases for performance. As anyone who ever built database applications knows an improperly designed database can be the biggest impediment to flawless application performance.
The chapter titled "Tactical Dispositions" covers the topic of indexing and in "The Nine Situations" the author examines several calssic SQL patterns and how best to approach them.
This book is not for a novice who wants to learn SQL from scratch. The authors assume the reader is conversant with SQL as they describe how to apply SQL in a practical manner. If you can't code an outer join or don't know what a nested table expression or in-line view is, then this is not the book for you.
Neither is the book a list of SQL scripts that you can pluck out and use. Instead, The Art of SQL skillfully manages to explain how to properly attack the job of coding SQL to effectively and efficiently access your data. The book offers best practices that teach experienced SQL users to focus on strategy rather than specifics.
The Art of SQL skillfully manages to explain how to properly attack the job of coding SQL to effectively and efficiently access your data. The book offers best practices that teach experienced SQL users to focus on strategy rather than specifics." You know, if Sun Tzu coded SQL, he might have written a book like "The Art of SQL". But since Sun Tzu is dead, I'm glad Stephane Faroult is around to author this tome.
The final SQL book recommendation is the latest edition of SQL for Smarties by the grand master of SQL, Joe Celko. Celko was a member of the ANSI SQL standards committee for ten years, and is highly qualified to write such a text. The latest edition of this fine book is the 3rd edition, which has been completely revised and boasts over 800 pages of advanced SQL programming techniques. If you have one of the past two editions of this book, you owe it to yourself to get the newly revised third edition. This book offers tips, techniques, and guidance on writing effective, sometimes complex, SQL statements using ANSI standard SQL. It touches on topics ranging from database design and normalization to using proper data types to grouping and set operations, optimization, data scaling, and more. Every developer who codes SQL statements for a living will find something useful in SQL for Smarties!
Joe also wrote an introductory SQL book titled SQL Programming Style (Morgan Kaufmann: ISBN 0-12-088797-5) that offers useful guidance on how to write standard SQL. If SQL for Smarties is too much for you, start off with SQL Programming Style. As most readers of my blog know, I am a huge advocate for continuing education, and technical books are a fine way of building your knowledge. Any one of the books discussed here, or indeed all of them, will be helpful to professional SQL developers... or those who aspire to be.
|
-
Regular readers of my blog know that I also participate in the micro-messaging phenomenon Twitter (www.twitter.com/craigmullins). If you've tried Twittering you know that it can be addictive, but it is also growing in popularity as a business tool for communication. This might seem hard to believe when you first dive into Twitter-ing. The basic idea of Twitter is simple: provide a platform for users to publish messages of no more than 140 characters at a time. And that can seem limiting... until you've used Twitter for awhile. If you subscribe to my Twitter feed you'll find that I send out regular Tweets (that is what a Twitter message is called) for many things, such as: - when I post a new blog entry (maybe you got here that way),
- to share the highlights of interesting sessions when I attend a conference or user group,
- to notify folks when I've published a new article or column, and
- just to share some of the "things" going on in my life.
OK, so what are the business uses of Twitter? Well, sharing information (like I do) is absolutely a business usage. But if you are interested in learning more about that check out the new O'Reilly Radar report titled Twitter and the Micro-Messaging Revolution:
Communication, Connections, and Immediacy--140 Characters at a Time. This informative new report documents many practical uses for micro-messaging on Twitter, including: - Best practices for micro-messaging in business
- Pitfalls to avoid in this instant, very public medium
- New methods for customer service and quick market research
- How micro-messaging can help you reduce email and eliminate unproductive meetings
My favorite example of using Twitter in a novel way with actual benefits? The just-completed presidential elections.This report uncovers how Twitter experienced spikes in messages during each of the four televised debates associated with the U.S. presidential elections.To help connect people around the debates and the election generally, Twitter introduced Election 2008 (http://election.twitter.com/), a site that streamed election-related Twitter posts. And who has more followers than anyone on Twitter? President-elect Barack Obama. Y'know, maybe there is something to this Twitter thing, after all...
|
-
Rigidly adhering to a standard, any standard, without being reasonable and using your ability to think through changing situations and circumstances, is itself, a bad standard. ![]()  If you are a Monty Python fan you probably recognized the title of this blog entry. It is the unchanging statement of the black knight in Monty Python and the Holy Grail. He just stands there blocking everyone who attempts to go past him - even after a better swordsman has cut off all his arms and legs. I'm sure some of the application developers can relate to that. Valiantly explaining to the DBA why they need to go against some standard or another, only to be told "None shall pass" by that stubborn DBA.
For just about every standard you can think of, I can think of an exception. A good standard should be put in place not to be a rigid bottleneck to productivity. Instead, a good standard is there because it works well most of the time in terms of delivering superior service, availability, or functionality. But sometimes, diverting from that standard can make sense, too. The key is for DBAs to keep an open mind and to be reasonable. Of course, I do not mean to suggest that developers should be allowed to thwart the written standards of the organization whenever they see fit. Instead, all parties involved should be reasonable and have a valid, business reason for failing to enforce a standard. When going against a standard makes more sense than enforcing it, let's all agree that it is wiser to make an exception. After all, our standards are supposed to be there to make sure we do the right thing. And they normally do... except when they don't.
|
-
Today's blog entry on bad database standards is a little different than the previous ones we've discussed. In this case, the bad standard is that there is no formal standard. The first three entries in our on-going "bad standards" series dealt with common, existing standards that are either outdated or not well thought-out. This time, though, we tackle a standard that is "bad" because it most likely does not exist. Very few shops have written a standard like the one I'm about to outline. It is undeniable that data growth is out of control. Businesses today are gathering and storing more data than ever before. And 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. But rarely is there a uniform, guiding data infrastructure in place that dictates when, why, how, and where data is to be stored.
But I'm getting ahead of myself a bit here. The missing standard that I am proposing is one that limits copies of the same data. One of the biggest contributors to data growth is that we copy and store the same data over and over and over again. It may reside in the production system in a DB2 database on the mainframe (and, oh yes, it was copied from an IMS database that still exists because there are a few transactions that have yet to be converted). And then it is copied to the data warehouse (perhaps running Oracle on a Unix server), an operational data store, several data marts, and maybe even to an ad hoc SQL Server database in the business unit... and don't forget those users who have the same data in an Excel spreadsheet on their desktop. This just has to stop!
A DBMS is a viable, useful piece of software because it enables multiple users and applications to share data while ensuring data integrity and control. But human nature being what it is, everyone wants their own copy of the data to "play with" and/or manipulate. But at what cost? Data storage requirements are but one, small piece of the cost. The bigger cost is the data integrity problems that are created. If you have customer data (for example) spread across 5 platforms, 4 database systems, and 3 different locations what do you think the chances are that all of that data will be accurate? My guess would be that there is a zero percent chance!
So we need to create standards that control, prohibit, and limit the mass duplication of data that is rampant within today's companies. Of course, to do so requires a data management discipline to be enacted such that data is available and accurate to all potential consumers. If the data can be accessed efficiently from a single location, or at least fewer locations, we can reduce the amount of data we need to manage and improve data quality.
Doesn't that sound like a win/win scenario?
|
-
Tonight's entry continues our on-going series on "bad" database standards. And the "bad" standard we'll discuss tonight is a particularly nasty one. Although the general idea behind this standard might seem to be understandable, at least at first blush, the implementation and wording is typically all wrong, wrong, wrong. OK, so what am I talking about? Well, the way this "bad" standard typically is stated is something like this: "Code no more than a 3 table join in any program that is accessed in an online environment." The idea is to limit the amount of work that is done by a transaction so that it can be accomplished in a limited amount of time. Given that there is a user waiting for a response you do not want the transaction to take an inordinate amount of time. Why is this wrong? Well, the general idea behind the standard is not necessarily wrong, but the standard is. Whether it says a 3 table join or a 5 table join (or some other number) is not important. The number of tables participating in a join is not the defining factor for performance. Instead, it is the number of qualifying rows to be returned. A well defined query that specifically limits the data to be returned appropriately, can be very efficient whether it is a single table access or a multiple-table join. So do not place artificial limits on the number of tables that can participate in a join. Each DBMS has its upper limit and, of course, you cannot exceed that (for example, 225 table in DB2 for z/OS). Another misunderstanding is when standards are written that "worry" about the size of tables. Once again, this factor is not necessarily important -- instead it is the number of qualifying rows again. Consider, for example, a table with 10 million rows in it. A query that uses a matching index to return 2 rows from that table can be very efficient. On the other hand, a query against a smaller table, say 100 pages, that must scan data will likely consume more resources and take longer to complete than the indexed access against the bigger table. The number of rows that qualify for the predicates is more important than the size of the table. You should create standards and guidelines that help your application developers and SQL users to create efficient queries instead of creating arbitrary standards based on table size or number of tables in a join.
|
-
Today's entry, the second in a continuing series on bad database standards, attacks the misguided notion of putting too many columns in the SELECT-list of your SQL statements.
Database application performance can be impacted by many factors - but the number one cause of poor relational performance is usually poorly coded SQL. Sometimes, the mistakes are simple to correct - and that is the case with this week's "bad standard."
One of the simplest mistakes made by many SQL programmers is including too many columns in the SELECT-list of their SQL statements. The only columns that should be included in the SELECT-list are those that are needed to meet the business requirements of the query. Sometimest this is simplified to "avoid SELECT *". That is actually a good standard (excepting, of course, quick & dirty ad hoc queries), but it does not capture the true requirement, that being to reference only exactly what is required and nothing more.
The bad standard may read something like this: Every column referenced in a WHERE clause of your SQL statement(s) should also be included in the SELECT-list of that statement.
That is an extremely nasty standard. Some shops do it to support their development tools or to standardize (for some strange reason). But all that it does is build performance degradation into your applications. Consider the following statement:
SELECT FIRSTNAME, LASTNAME, EMPNO
FROM EMPLOYEE
WHERE EMPNO = '700';
You might be asking something like "What is so wrong with that statement?" Well, there is no reason for EMPNO to be in the SELECT-list. We know its value will always be 700 because of the WHERE clause.
OK, but that is a small issue, right? Maybe. What if this statement runs thousands of times a day? Every column that the DBMS must pick up and return to the application requires additional resources - a small amount of resources, but additional resources none-the-less. If we remove the column from the SELECT-list we remove the requirement to use those resources. Now multiply that by the thousands of times the statement runs and we're saving something!
The bottom line is that a standard forcing the column into the SELECT-list has no viable reason to exist -- and at worst, it can cause a performance problem. So, if something like this is in your company's standards manual, snip it right out today.
|
-
With this blog entry I start a new series discussing bad database standards. Almost every DBA group keeps a database standards manual - but most do not keep it up-to-date. I'll try to tackle some of the more popular standards that should be done away with.
Just about every company with a DBMS has that binder full of corporate and/or IT standards. You know, it is that one over there in the corner with the cobwebs on it? The one that you only use when you need an excuse to avoid work… OK, well, maybe its not quite that bad.
Basically, what happens is that some well-meaning authority comes up with a “rule” or “guideline” that makes sense at some point – and then decides to enshrine it for eternity in the standards manual. Now don't get me wrong, company standards can be a very good thing. It is the eternity part that I take exception with. Standards need to be a living, breathing "thing" that change with the times.
You see, standards can be worthwhile as a measuring stick to work from, hopefully ensuring that reliable and efficient databases and applications are built in a standard manner. But a rule that made sense 10 or 20 years ago probably is no longer reasonable. Every standard in your book should be reviewed at least annually to determine whether it is still reasonable to enforce.
One such rule is today’s topic, and if a form of it still exists in your standards manual drop everything you were going to do today and expunge it immediately from your standards book.
There should be no arbitrary limit on the number of indexes that you can create for any database table. Indexes are undoubtedly one of the most important factors in creating efficient queries. Relational optimizers rely on indexes to build fast access paths to data. Without indexes data must be scanned – and that can be a long, inefficient means by which to retrieve your data. When a rule such as this exists, it usually is stated in the standards manual using verbage something like this:
- “Each table can have at most 5 indexes created for it” - or -
- “Do not create more than 3 indexes for any single table in the database.”
These are bad standards. Very bad standards. Horrible standards. If you already have 3 indexes, or 5 indexes, or even 32 indexes, and another index will improve performance why would you arbitrarily want to avoid creating that index?
Anyway, a good indexing standard, if you choose to have one, should read something like this: “Create indexes as necessary to support your database queries. Limitations on creating new indexes should only be entertained when they begin significantly to impede the efficiency of data modification.”
Now that is a good standard! But most standards do not read that way because they are not easy to impose without arbitrary numbers and restrictions embedded within them.
I intend to take on other nasty standards that should be eliminated in subsequent blog entries here. Please feel free to e-mail me your favorites (or perhaps I should say least favorites) standards that should be eliminated. Or leave a comment below. I’d be happy to take them on here for you.
|
-
Heads-down DBAs who know technology, but not their company's business, soon will be on the endangered species list. So number 8 on our list of DBA rules of thumb is to develop business acumen and learn to be a Business Savvy DBA! Although DBAs are technologists first and foremost, we need to be ever cognizant of the business reasons that our beloved technologies support. Yes, DBAs like to immerse themselves in the bits and bytes of technical solutions and learn all there is to know about the software we use. And this is okay--up to a point. As long as we take care not to blind ourselves to the business reasons for the software and hardware we enjoy. To keep the business "top of mind," the DBA's tools and utilities need to be tied to business strategies and initiatives. In this way, the DBA's work becomes integrated with the goals and operations of the organization. The first step in achieving this needed synergy is the integration of DBA services with the other core components of the IT infrastructure. Of course, the DBA should be able to monitor and control the databases under his purview, but he should also be able to monitor them within the context of the broader spectrum of the IT infrastructure--including systems, applications, storage, and networks. Only then can companies begin to tie service-level agreements to business needs, rather than technology metrics. To fulfill the promise of business/IT integration, it will be necessary to link business services to the underlying technology. For example, a technician should be able to immediately comprehend that a service outage to transaction X7R2 in the PRD2 CICS region means that regional demand deposit customers cannot access their accounts. There is a big difference in the language! Focusing on transactions, TP monitors and databases is the core of the DBA's job. But servicing customers is the reason the DBA builds those databases and manages those transactions. Technicians with an understanding of the business impact of technology decisions will do a better job of servicing the business strategy. This is even more true for the DBA's manager. Technology managers who speak in business terms are more valuable to their company. Of course, the devil is in the details. A key component to realizing effective business/IT integration for DBAs is the ability to link specific pieces of technology to specific business services. This requires a service impact management capability--that is, analyzing the technology required to power each critical business service and documenting the link. Technologies exist to automate some of this through event automation and service modeling. Such capabilities help to transform availability and performance data into detailed knowledge about the status of business services and service level agreements. Today's modern corporation needs technicians who are cognizant of the business impact of their management decisions. As such, DBAs need to get busy transforming themselves to become more business-savvy. And that means, at a minimum, keeping an eye on the business impact of the technology under their span of control.
|
-
A good DBA is a Jack-of-All-Trades. You can't just master one thing and be successful in this day-and-age. So number 7 in this on-going series of DBA rules of thumb is to diversify your skill set.
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, he 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.
To add to the chaos, DBAs are expected to know everything about everything. 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.
When application problems occur, the database environment is frequently the first thing blamed. The database is "guilty until proven innocent." A DBA is rarely approached with a question like "I've got some really bad SQL here. Can you help me fix it?" Instead, the DBA is forced to investigate problems where the underlying assumption is that the DBMS or perhaps the DBA is at fault, when the most common cause of relational performance problems is inefficiently coded applications.
Oftentimes the DBA is forced to prove that the database is not the source of the problem. The DBA must know enough about all aspects of IT to track down errors and exonerate the DBMS and database structures he has designed. So he must be an expert in database technology, but also have semi-expert knowledge of the IT components with which the DBMS interacts: application programming languages, operating systems, network protocols and products, transaction processors, every type of computer hardware imaginable, and more. The need to understand such diverse elements makes the DBA a very valuable resource. It also makes the job interesting and challenging.
So there are core, fundamental skills that a DBA must possess in order to succeed. I have narrowed that list down to 17 essential skills (and published that list in my DBA Corner column, which runs in each issue of Database Trends & Application magazine). These skills are necessary, but are not, in and of themselves, enough to make you the best DBA you can possibly be. No, you will need to diversify into other areas to excel... Jack-of-All-Trades Getting to the heart of the matter, a DBA has to diversify. Why?
Databases are at the center of modern applications. If the DBMS fails, applications fail, and if applications fail, business can come to a halt. And if business comes to a halt often enough, the entire business can fail. Database administration is therefore critical to the ongoing success of modern business.
Databases interact with almost every component of the IT infrastructure. The typical IT infrastructure of today comprises many tools:
- Programming languages and environments such as COBOL, Microsoft Visual Studio, C/C++, Assembler, and Java
- Database and process design tools such as ERwin, ER-Studio, and Rational
- Transaction processing systems such as CICS and BEA
- Message queueing software such as MQSeries and MSMQ
- Networking software and protocols such as SNA, VTAM, TCP/IP, and Novell
- Networking hardware such as bridges, routers, hubs, and cabling
- Multiple operating systems such as Windows, Mac OS X, z/OS and MVS, UNIX, Linux, and perhaps others
- Data storage hardware and software such as enterprise storage servers, Microsoft SMS, IBM DFHSM, storage area networks (SANs), and NAS
- Operating system security packages such as RACF, ACF2, and Kerberos
- Other types of storage hardware such as tape machines, silos, and solid state (memory-based) storage
- Non-DBMS data set and file storage techniques such as VSAM and B-tree
- Database administration tools
- Systems management tools and frameworks
- Operational control software such as batch scheduling software and job-entry subsystems
- Software distribution solutions for implementing new versions of system software across the network
- Internet and Web-enabled databases and applications
- Client/server development techniques such as multitier, fat server/thin client, thin server/fat client
- Object-oriented and component-based development technologies and techniques such as CORBA, COM, OLE DB, ADO, and EJB
- PDAs and SmartPhones such as the Blackberry, Palm Treo, and PocketPC.
Although it is impossible to become an expert in all of these technologies, the DBA should have some knowledge of each of these areas and how they interrelate. Even more importantly, the DBA should have the phone numbers of experts to contact in case any of the associated software and hardware causes database access or performance problems.
So, being a DBA is sorta like structuring a well-invested financial portfolio: to be successful at either, you will need to diversify!
|
-
Most every IT professional continually looks for their company to invest money in on-going education. Who among us does not want to learn something new - on company time - and with the company's money? Unless you are self-employed, that is! So number 6 in our on-going DBA rules of thumb series is to invest in yourself.
I don't want you to read too much into that. I am not saying all educational expenses should be the employee's responsibility. Your company should invest some funds to train you on new technology and new capabilities - especially if it is asking you to do new things. And since technology changes so fast, most everyone has to learn something new at some point every year. But the entire burden of learning should not be placed on your company!
Budget some of your own money to invest in your career. After all, you probably won't be working for the same company your entire career. Why should your company be forced to bankroll your entire ongoing education? Now, I know, a lot depends on your particular circumstances. Sometimes we accept a lower salary than we think we are worth because of the "perks" that are offered. And one of those perks can be training.
But some folks simply abhor spending any of their hard-earned dollars to help advance their careers. Shelling out a couple of bucks to buy some new books, subscribe to a publication, or join a professional organization shouldn't be out of the reach of most folks in IT, though.
A willingness to spend some money to stay abreast of technology is a trait that should apply to DBAs. Most DBAs I've known are insatiably curious and many are willing to invest some of their money to learn something new. Maybe they bought that book on XML before anyone at their company started using it. Perhaps it is just that enviable bookshelf full of useful database books in their cubicle. Or maybe they paid that nominal fee to subscribe to the members-only content of that online portal. And they could even have forked over the $10 fee to attend the local user group.
Don't get me wrong. I'm not saying that companies should not reimburse for such expenses. They should - it provides for better-rounded, more educated, and more useful employees. But if your employer won't pay for something that you think will help your career, then why not just buy it yourself?
And be sure to keep a record of such purchases because unreimbursed business expenses can be tax-deductible. And while you're at it, stop spending the company's time and money web surfing, shopping, etc. instead of taking that same time to learn something new.
Now I know, that sometimes we work such long hours that we need to check things online or make personal calls. That is not what I'm talking about. We all know that there are employees who waste A LOT of time browsing the web for personal reasons. Instead, browse for educational "things" - or read a technical book - or ... you get the idea. So, open up that wallet and spend some cash on yourself... after all, are you worth investing in or not?
|
-
In a complex, heterogeneous, distributed world it can be hard to keep your eye on the right ball, at the right time. So number 5 in our continuing series of DBA rules of thumb is to make sure that you "Focus Your Efforts!" The job of a DBA is complex and spans many diverse technological and functional areas. It is easy for a DBA to get overwhelmed with certain tasks – especially those tasks that are not performed regularly. The best advice I can give you is to remain focused and keep a clear head. Understand the purpose for each task you are going to perform and focus on performing the steps that will help you to achieve that purpose. Do not be persuaded to broaden the scope of work for individual tasks unless it cannot be avoided. In other words, don’t try to boil the ocean. If non-related goals get grouped together into a task it can be easy to work long hours with no clear end in sight. I am not saying that a DBA should (necessarily) specialize in one particular area (e.g. performance). What I am suggesting, is that each task should be given the appropriate level of focus and attention to details. Of course, I am not suggesting you should not multi-task either. The successful DBA will be able to multi-task while giving his or her full attention to each task as it is being worked on. What is the enemy of focus? There are many: distraction, lack of knowledge, "management", and always worrying about the "next thing" to try or do. Such disctractions can wreak havoc on tasks that require fore-thought and attention to detail. Analyze, simplify, and focus. Only then will tasks become measurable and easier to achieve.
|
-
A calm disposition and the ability to remain cool under strenuous conditions are essential components of the makeup of a good DBA. So number four in our series of DBA rules of thumb is "Don’t Panic!" I used to have a big orange button with the words "Don't Panic!" on it hanging up in my office. Fans of Hitchhiker's Guide to the Galaxy will recognize the phrase, and I think I got the button in a software game based on those books back in the 1980s. I gave it away a long time ago to a friend when I left one of the company's I was working at as a DBA. He needed it more than I did at the time! But I always kept that mantra in the back of my head as I continued along my journey as a DBA. Problems will occur – there is nothing you can do to eliminate every possible problem or error. Part of your job as a DBA is to be able to react to problems with a calm demeanor and analytical disposition. When a database is down and applications are unavailable your environment will become hectic and frazzled. The best things you can do when problem occur is to remain calm and go about your job using your knowledge and training. As the DBA you will be the focus of the company (or at least the business units affected) until the database and applications are brought back online. It can be a harrowing experience to recover a database with your boss and your users hovering behind your computer terminal and looking over your back. Be prepared for such events because eventually they will happen. Panicking can cause manual errors – the last thing you want to have happen when you are trying to recover from an error. The better you perform up-front planning and the better your procedures, the faster you will be able to resolve problems. And if you are sure of your procedures you will remain much calmer. Following these basic maxims will make database administration a much more manageable task within your organization.
|
-
Knowledge transfer is an important part of being a good DBA - both transfering your knowledge to others and participating in having others' knowledge transferred to you. So be sure to share your knowledge freely with others in need instead of hoarding it, thinking that it buys you job security.
The more you learn as a DBA, the more you should try to share what you know with other DBAs. Local database user groups typically meet quarterly or monthly to discuss aspects of database management systems. Healthy local scenes exist for DB2, SQL Server, and Oracle: be sure to attend these sessions to learn what your peers are doing.
And when you have some good experiences to share, put together a presentation yourself and help out your peers. Sometimes you can learn far more by presenting at these events than by simply attending because the attendees will likely seek you out to discuss their experiences or question your approach. Technicians appreciate hearing from folks in similar situations... and they will be more likely to share what they have learned once you share your knowledge.
Another avenue for sharing your knowledge is using one of the many online database forums. Web portals and web-based publications are constantly seeking out content for their web sites. Working to put together a tip or article for these sites helps you arrange your thoughts and to document your experiences. And you can garner some exposure with your peers by doing so because most web sites list the author of these tips. Sometimes having this type of exposure can help you to land that next coveted job. Or just help you to build your peer network.
Finally, if you have the time, considering publishing your experiences with one of the database-related print magazines. Doing so will take more time than publishing on the web, but it can bring additional exposure. And, of course, some of the journals will pay you for your material.
But the best reason of all to share your knowledge is because you want others to share their knowledge and experiences with you. Only if everyone cooperates by sharing what they know will we be able to maintain the community of DBAs who are willing and eager to provide assistance.
Here are some valuable links for regional and worldwide database user groups:
|
|
|
|