- It includes such topics as:
- Database Storage
- Physical Database Design
- Data Life Cycle Management
- Minimizing Planned Outages
- IBM Data Server Security
- Deploying IBM DB2 Products
- Writing and Tuning Queries for Optimal Performance
- Tuning and Monitoring Database System Performance
- Deep Compression
- Managing XML Data
- Improving Data Server Utilization and Management through Virtualization
- and of course my favorite which I posted about earlier the Frequently Asked Questions from Problem Management Reports
News and information from the DB2 LUW Technical support team.
I know I wrote about this earlier but some of the topics have been updated so it's a good time for a reminder.The following site has some great Best Practices for DB2 for Linux, UNIX, and Windows
Today's post comes from Harjit Thind.
Harjit is a DB2 LUW support analyst that has been with the DB2 support team since 2000. As well as his DB2 LUW skills Harjit is also knowlegeable on Datalinks and BCU.
Runstat and reorgchk should be run on a regular basis.. whereas reorg on tables should be run on an as needed basis depending on the output from reorgchk.
Now, how to make a descision if a reorgchk needs to be run or not.
Table reorganization is suggested when the results of the calculations exceed the bounds set by the formula.
For example, --- indicates that, since the formula results of F1, F2, and F3 are within the set bounds of the formula, no table reorganization is suggested. The notation *-* indicates that the results of F1 and F3 suggest table reorganization, even though F2 is still within its set bounds. The notation *-- indicates that F1 is the only formula exceeding its bounds.
Index reorganization advice is as follows:
Today's post is provided by our guest blogger Shakil Choudhury.Shakil is a member of the DB2 LUW U.S. support team and has been dedicated to providing client success for over 5 years.
Database Administrators sometimes may need to restore a portion of their databases from Production to a Test environment for various reasons, ( testing etc ). They need to restore a small portion of their Production database because the Production database is too big to restore in test env and/or the Production database restore takes a very long time.
It was not possible to do this prior to Version 9.1.
In Version 9.1 DB2 offers partial restore ( tablespace level ). The following example shows how to do that and it also explores a specific case where two tablespaces have dependencies in the database.
The example below shows that one table has been created in one tablespace and its CLOB data is kept in different tablespace and the DBA decides to avoid these two tablespaces ( partial restore ) and what a DBA may face after the restore is completed and are about to drop those tablespaces.
In DB2 Version 9.1 we have options of restoring a database without some of the tablespaces. This is new in V9.1.
The following shows a step by step test.
Lets first create a database name Testdb. Then create two tablespaces.
Tablespace creation syntex is not given here.
I have created one tablespace name myspace3 ( regular ) and which is DMS
I have Created another tablespace name myspace4 ( large ) and which is DMS
Create one table MYTABLE1 in myspace3, and insert some values in table MYTABLE1.
Then create another table MYTABLE2 in myspace3 with CLOB field and then make sure CLOB field goes to large tablespace myspace4.
Insert some values in the MYTABLE2.
Then do a offline backup of the database Testdb and then drop the database.
Then do a redirected restore of the database as below:
db2 "restore db Testdb rebuild with all tablespaces in image except tablespace (myspace3,myspace4) from '/home/shakilc/backup' into Newdb redirect"
db2 restore db testdb continue
db2 connect to Newdb.
db2 list tablespaces show detail
You will see:
Tablespace ID = 3
Tablespace ID = 4
You will also see more tablespaces but for the sake of this doc, I am not showing those.
/home/shakilc: db2 drop table MYTABLE1
/home/shakilc: db2 drop table MYTABLE2
/home/shakilc: db2 drop tablespace MYSPACE3
/home/shakilc: db2 drop tablespace MYSPACE4 DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0282N Table space "MYSPACE4" cannot be dropped because at least one of the tables in it, "SHAKILC.MYTABLE2", has one or more of its parts in another table space. SQLSTATE=55024
Trick here is to drop both tablespaces in the same statement:
db2 => drop tablespace myspace3,myspace4
Now you have databases without two tablespaces ( myspace3 and myspace4 ).
You can drop a user table space that contains all of the table data including index and LOB data within that single user table space. You can also drop a user table space that might have tables spanned across several table spaces. That is, you might have table data in one table space, indexes in another, and any LOBs in a third table space. You must drop all three table spaces at the same time in a single statement. All of the table spaces that contain tables that are spanned must be part of this single statement or the drop request will fail.
Restore command:Read More]
There you are merrily going about your DB2 LUW work when you have to call in to get some assistance on a problem you've encountered. Little do you know that the first words you may hear from a support analyst are, "That version of DB2 is out of support"
Unlike many other products out there today, software doesn't have a best before date on the box and smelling the CD/DVD's to see if it is still fresh will only get you some strange looks. In many cases you probably don't even have a box or a CD/DVD as you downloaded the product from Passport Advantage. How are you supposed to know that a product is going out of support?
The IBM Software Support Lifecyle web site holds the key to that freshness
What better way to start off a blog about DB2 LUW Support than to talk about FAQ's.
I'm a little behind the ball on this as others have already blogged / posted about the existance of a document that has DB2 LUW's most frequently asked and answered questions in it.
What I do have over those other blogs is that I actually work closely with technical team of support analysts that get the calls and answer those questions. Most of the information is out there on the web someplace. In the Info Center or in Technotes but to my knowledge we have never taken all the most common questions and put them in a single document.
That document now resides here.