DB2 data locked away forever?

Leslie Noth

Hi there,

I have build a J2EE web application that uses DB2 UDB for Windows
(2000) to store it's data.

This application had been up-and-running for over 2 years but needed
to be relocated on another machine.

So, after making a back-up of the C:\DB2 directory (which we thought
would contain all our precious data!) the disk was thoroughly cleaned
and the server was given to someone else.

The problem we are facing now is that I cannot access that data
anymore ?!

I have DB2 UDB (7.2) on my laptop and just renamed the existing DB2
directory and replaced it with the saved one.

The control center recognizes that the database exists (because when I
try accessing a non-existing database name I get another error) but
when I want to access the data the error is: SQL1036C An I/O error
occurred while accessing the database. SQLSTATE=58030

Here are my questions:

-I think this could be a version problem, how can I retrieve the
version from the database if I cannot connect to it? I hope it stores
this info.

-Are there any tools that can help me recover the data, it is really
very, very important to get it back!

The version I use on my laptop is: DB2 Universal database, Enterprise
Edition Version 7.2 fixpack 12.

The version of DB2 as it existed previously on the server is not
exactly known but not very much older or newer than this one. (7.x
probably)

Please help!
Leslie
Amsterdam, Holland

Nov 12 '05 #1

Jan M. Nelken

Leslie Noth wrote:

So, after making a back-up of the C:\DB2 directory (which we thought
would contain all our precious data!) the disk was thoroughly cleaned
and the server was given to someone else.

The problem we are facing now is that I cannot access that data
anymore ?!

I have DB2 UDB (7.2) on my laptop and just renamed the existing DB2
directory and replaced it with the saved one.

Bad idea. Is there any reason you did not use DB2 Backup and Restore method -
this is only supported one?

What happens if you:

1. Drop all existing databaases on your laptop. so this command will tell you
that system database directory is empty:

db2 list db directory
2. Restore from the backup of C:\DB2 subdirectories.

3. Issue:

db2 list database directory on C

If this command actually outputs database name of the database you are
interested in, then:

4. db2 catalog db <databasenamehere> on C

and try to connect to it. The only purpose of the connection should be to verify
that you can do this. You should then to proceed with exporting all data in IXF
format - to verify that you can access all rows correctly. If succeeded - drop
this database, ctreate a new empty one and reimport all data from .IXF files.

Needless to say - backup and restore on file system level of DB2 objects is not
supported.

Jan M. Nelken

Nov 12 '05 #2

Leslie Noth

Jan wrote:

What happens if you:

This is the output from the list db directory on C before any drop
commands.

Local Database Directory on C

Number of entries in the directory = 7

Database 1 entry:

Database alias = ABC_DEF
Database name = ABC_DEF
Database directory = SQL00006
Database release level = 9.00
Comment =
Directory entry type = Home
Catalog node number = 0
Node number = 0

Database 2 entry:

etc.

I can catalog the databases but I cannot drop them, same error:

SQL1039C An I/O error occurred while accessing the database
directory.
SQLSTATE=58031

Needless to say that connecting doesn't work either.

I don't understand what's happening, if one of the seven databases
would be corrupt I could understand it but none of them work.
I'm sure that most of the databases didn't even have a connection to
them at the time of the back-up.

Do you have any more suggestions...

Leslie

Nov 12 '05 #3

Leslie Noth

12***@vizzavi.nl (Leslie Noth) wrote in message back-up.

Do you have any more suggestions...

Leslie

Since no one replied I decided to give it one more try myself.

After reading about DB2 on Unix and file permissions, I checked the
DB2 directory.
It appeared that some DB2 files were read-only, which would explain
the I/O error.

So, after making them all readable I was able the access the database
again.

The data was not corrupted and the application is now running smoothly
on a new server.

Regards,
Leslie

Nov 12 '05 #4

Jan M. Nelken

Leslie Noth wrote:

After reading about DB2 on Unix and file permissions, I checked the DB2 directory.
It appeared that some DB2 files were read-only, which would explain the I/O error.

So, after making them all readable I was able the access the database again.

The data was not corrupted and the application is now running smoothly
on a new server.

I would rather issue (after stopping instance - as root - db2iupdt.

This will ensure proper permission for the instance files. On Unix some of the
files have to have s bit on.
Jan M. Nelken

Nov 12 '05 #5