Drop and Create alias statements took a long time (7.2 FP7, AIX)

[tom horner]

Any ideas on why drop and create alias statements would take a long
time?

We recently went through an upgrade of our production database, which
included alter statements to table structures, create tables, drop
tables, and data inserts, deletes, and updates. Also, we dropped and
recreated all the alias's we had on the tables and views to those
tables. We are on UDB 7.2, FP7, on AIX.

Everything took about the same time as in our testing, except the drop
and create of alias's. The dropping of the aliases took about 8 min,
while the creation of aliases took about 7 min. In testing (same
number of drops and creates), it took about a minute. There were 367
alias's dropped and recreated. All were successful, and nothing is in
the diagnostic log at the time this shell was run. It just took a
LONG time (about 15 minutes total)!

I realize that a lot of factors could account for this, but the test
and production machines have comparable "power" (CPU, memory). They
do have different dbm and db cfg's. However, the test box cfg's are
basically the defaults, while the production box has been "tweaked"
for performance. However, should cfg values even have any major
impact on this type of SQL? Also, the other statements (alters, etc.)
which I would consider much more "complex" did not take any longer
than our test runs.

My question is, has anyone else come across this anomoly? I checked
IBM's site and this site and found nothing about this.

Details of the script...grants alias.sh does the following:

1. Drops the alias for each table and view (e.g. drops the alias
KBCPRO.USER)
2. Creates the alias for each table and view (e.g. creates the alias
KBCPRO.USER)

Thanks in advance!

Tom Horner, Production DB2 DBA

[Serge Rielau]

I can only imagine concurrency issues on SYSIBM.SYSTABLE S.
Especially creating aliases is pretty much a no-op.
Dropping an alias teher is soem depenency work going on, but still....
Any other sessions that do DDL concurently which may hold u or x locks
on above table?

Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[tom horner]

No other sessions. We were in the middle of a production upgrade
which meant no users on the system. The alias statements were done
after the other alters, etc.

Thanks for the response and thanks in advance for any other ideas!

Serge Rielau <sr*****@ca.e ye-bee-m.com> wrote in message news:<br******* ***@hanover.tor olab.ibm.com>.. .

I can only imagine concurrency issues on SYSIBM.SYSTABLE S.
Especially creating aliases is pretty much a no-op.
Dropping an alias teher is soem depenency work going on, but still....
Any other sessions that do DDL concurently which may hold u or x locks
on above table?

Cheers
Serge