Many DBAs who have been DBAs for a while have been bitten by executing an SQL script, not thoroughly checking the output, and finding later that one or more statements in the SQL script failed. I have certainly been guilty of this at times.
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.
(Edited 8/12/2014 to add links to the old tutorials from IBM)
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.
What is a Storage Group?
A storage group is a layer of abstraction between the data in your database and disk. It is only used with Automatic Storage Tablespaces (AST). It allows us to group tablespaces together to live in similar places. Storage groups were first introduced in a roundabout way with automatic storage databases in DB2 8.2. These databases allowed you to specify one or more paths for the entire database, and DB2 would manage spreading the data across them. It soon became clear that a level between the old school “control where everything goes” and the newer “I don’t care, just spread it across as many read/write heads as possible” was needed. Personally, I’m just fine with having only two locations for my data. I could manage that just fine in with the old methodology with DMS tablespaces, and I manage it just fine in my more recent databases with storage groups.
Are you ready yet? Have you started to throttle your work for the week, arrange a backup, even packed a bag? The 2014 IDUG Technical Conference is only a week away.
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.
I’m so excited! The IDUG North American Technical Conference is less than a month away. Much like Melanie Stopfer mentioned in her blog entry on IDUG, this is one of MY favorite weeks of the year. There’s something about the IDUG conference. I have been to IBM’s DB2-related conference (which they’re now calling IBM Insight), and it was huge and interesting, but there is something more intimate about IDUG. It’s fun to see the same small group of friends each year and it’s a great place to make new DBA friends. I say friends rather than “contacts” because for me that’s more what this conference is about. Finding and catching up with people that I consider friends and talk to throughout the year. I’m a bit of an introvert, but for this one week, I become a social person, and it’s fun.
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.