QUESTION: Tablespace containers not being cleared...

[BD]

Hi, all.

Background:

Windows server 03 R2, running db2 8.2. Development environment.

I inherited this server some time ago, so do not have its entire
history available.

We have a routine script that is run, which drops the database,
recreates it, and reloads tables from DEL .CSV files.

The tablespace.log file has many occurrences of "SQL0294N The
container is already in use. SQLSTATE=42730", one for each tablespace
in the 'create tablespace' script.

The containers and files for the tablespaces all have a file creation
date of several months ago, indicating that they are not being deleted
and recreated as the database is dropped and recreated.

Running a 'list tablespaces' returns the names of SYSCATSPACE,
TEMPSPACE1, and USERSPACE1. There should be many more tablespaces.

I am theorizing that sometime in the past, the database was dropped or
deleted in an unclean fashion, and the container tags in the files are
still associated with the original database.

I am looking for a way to confirm this, and trying to understand what
I best do about it. My reading indicates that running the db2untag
utility should remove the tags and allow the files to be reclaimed by
the 'current' database. I also theorize from my reading that if I were
to drop the database again, and then simply delete all these
containers and files at the filesystem level, I should be able to
recreate the tablespaces with a clean database build.

But, I've not been able to confirm that the container tag is the
issue.

Does this make sense? Can anyone suggest what I might do to confirm
this theory, before I just start deleting files?

Thanks,

BD

[stefan.albert]

I remember a similar situation in the past - but I don't really know
if it was after a drop db...
May be there is still another DB somewhere? DB2TOOLS or something like
that...

A safe way will be to delete any containers left after the drop DB.
If you recreate the DB with existing files in the container
directories (SMS) the creation fails, because DB2 thinks that these
files belong to another database. I don't know what happens when using
DMS - might be the same...