If you’re mourning the loss of “RESET MONITOR ALL”, there are a number of ways you can address that. Ideally, you’d use this approach: http://www.ibm.com/developerworks/data/library/techarticle/dm-1009db2monitoring1/, but there are some arguments for using MONREPORT over that in some ways. One argument is that MONREPORT is built-in and you don’t have to add objects to make it work. The disadvantages are a bit less flexibility and the inability to use SQL to capture information. Though if it’s the old snapshot interfaces you miss, then the output from MONREPORT is more similar in a lot of ways.
I thought it would be relatively easy to investigate encryption for our environment. I was wrong, was just plain confusing. This was not because encryption is complicated per se, but that a DBA really needs to have a good understanding of business needs. If you don’t have this understanding, you can get lost in an array of options.
There are quite a few scenarios in which DBAs need to execute a script of SQL. Sometimes developers provide such a script to be executed. Sometimes we just have a large number of commands that need to be done as a whole.
There are a lot of things I can cover on db2top, and probably more tips and tricks using db2top than many other tools out there. Searching the web on db2top gets more good results than on many other db2 topics. I thought I’d start with some of the basics. Using db2top requires some general knowledge of how db2 works. I really debated whether it even qualified for my DB2 Basics series, but there are a few basic things that can help with using db2top.
My blog entries covering the DB2 Basics continue to be my most popular blog entries. This is probably because they appeal to a wider audience – even non-DBAs are interested in them and I continue to rank highly in Google search results. My blog entry on how to catalog a DB2 database gets a ridiculous 50 page views per day, which is more than my whole blog got per day for the first year I was blogging. I am also amazed that I can still come up with topics in this series – it seems like there are only so many things that count as “basics”. But there are a lot of different things in DB2 and some can be covered at a simple level.
This is the first in a series of blog entries on reorgs. I was talking with a friend recently, and he pointed out that I only have a few articles on reorgs, and they’re very specific to complicated parts of reorg. I have scripted my own reorgs and made a point of educating myself on reorg, so I’m starting with several basic articles and may add in some more advanced articles.
When does case matter in DB2? Well, it doesn’t unless it does. Nice and clear, huh?
This blog entry may be a little on the basic side, but some of my most basic entries are some of my most popular ones.
As with the other entries in my DB2 Basics series, this entry does not cover everything about triggers. Instead, I’m covering the basics and a few important points.
This is clearly a broad topic, and this post is intended to serve as an introduction.
Don’t call them indices in the United States – most American DBAs agree that they are ‘indexes’, though either plural form is grammatically acceptable in American English. Indexes are arguably one of the most important aspects of database design. They’re also something that we can pretty easily change and add to over time. Even overly restrictive vendors tend to allow new non-unique indexes to be added to their vended DB2 databases.