重置DB2表空间静默状态失败的例子

　　在重置DB2表空间静默状态时，有时会出现错误信息，下文就为您列举了一个重置DB2表空间静默状态失败的例子，供您参考研究  。

　　一种经常遇到的失败的重置操作：

　　由于静默操作导致的锁定的存在，对这样的DB2表空间进行某些操作时，可能会遇到 SQL3805N 或 SQL0290N 等报错信息，提示表空间不可访问  。例如以位于 DB2INST1.USERSPAC1 表空间的 DB2INST1.STAFF 表为例：

　　a) 静默表空间为意向更新状态：

　　db2 quiesce tablespaces for table db2inst1.staff intent to update

　　b) 尝试删除表的操作将失败：

　　db2 delete from db2inst1.staff
DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0290N Table space access is not allowed. SQLSTATE=55039

　　此时若使用：

　　db2 list tablespaces

　　命令检查DB2表空间状态，可以发现表空间 USERSPACE1 处于 INTENT TO UPDATE 的静默状态：

　　......
Tablespace ID = 2
Name = USERSPACE1
Type = System managed space
Contents = Any data
State = 0x0002
Detailed explanation:
Quiesced: UPDATE
......

　　如果要除去这一静默状态，可使用静默命令中的“RESET”选项，使DB2表空间恢复到正常状态（0x0000），从而实现对表空间中表的正常访问  。

　　此时，若尝试使用任何一个 DB2 用户，执行如下命令，进行除去该多DB2表空间的静默状态的尝试：

　　db2 quiesce tablespaces for table db2inst1.staff reset
DB20000I The QUIESCE TABLESPACES command completed successfully.

　　可以看到命令已成功完成，但当再次尝试上述的 DELETE 操作时，却仍然遇到同样的 SQL0290N 的报错，即不允许存取表空间  。查询表空间状态表明它仍处于原来的意向更新的静默状态  。为什么上述重置静默状态的命令已成功完成，却没有真正除去表空间的静默状态呢？