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
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
Comment