请教：关于利用数据链路建表死锁的问题？

cgh_chen

我说的应该是对的。
create table aaa as select * from aaa@link;
在将整个数据都从远程站点拉过来之后，才释放DDL锁

本地如此建表一样的道理 ：）

feng_xin

我曾经遇到过这种问题，在分布式数据库中使用
insert....select ... from ...
create ....select ... from .....
时有很多问题，分布式数据库加锁的方式与集中式的不同。后来改成游标的方式，所有的问题都解决。
我们当时的网络情况很复杂，有光纤、微波无线等，都有这个问题。

网络不稳定的时候，会出现会话中断引起的锁无法释放问题。因为UNIX缺省的TCP/IDLE参数是4个小时，由于网络问题引起的中断会话要4个小时后才会被PMON清理、释放锁。

jlandzpa

没错，在执行DDL的时候，不能执行desc。
如果DDL锁不释放，我们以后所有的过程都会等待。

最初由 cgh_chen 发布
[B]有可能在执行DDL的时候，都不能执行desc。
因为此时应该有DDL锁存在，desc无法执行，这儿DML锁不同的地方。
（个人看法，没有验证过） [/B]

jlandzpa

数据量不多。也就几千条，本来是应该几分钟就应该执行完的，
如果能够抱错，就不会影响下一次过程的执行了。

最初由 cgh_chen 发布
[B]我说的应该是对的。
create table aaa as select * from aaa@link;
在将整个数据都从远程站点拉过来之后，才释放DDL锁

本地如此建表一样的道理 ：） [/B]

feng_xin

最初由 jlandzpa 发布
[B]数据量不多。也就几千条，本来是应该几分钟就应该执行完的，
如果能够抱错，就不会影响下一次过程的执行了。
[/B]

我认为在分布式数据库的情况下
create table ... select * from  ..@link
与在集中式数据库的情况下
create table .... select * from .....
的加锁方式应该是不一样的，分布式数据库是两阶段提交，需要在两端数据库都加锁，我个人认为，任何一端的锁不能释放都会引起下个SESSION HANG。 希望高手能详细说明一下分布式数据库的加锁原理与机制。

Yong Huang

最初由 feng_xin 发布
[B]网络不稳定的时候，会出现会话中断引起的锁无法释放问题。因为UNIX缺省的TCP/IDLE参数是4个小时，由于网络问题引起的中断会话要4个小时后才会被PMON清理、释放锁。 [/B]

Where do you get the information that the default TCP "idle" time is 4 hours? What parameter are you talking about? Not sure what OS you have access to. In Solaris, type ndd /dev/tcp \? to get a list of the parameters and ndd /dev/tcp [the_parameter] to get its value. If you're talking about tcp_close_wait_interval, the default is 240,000 ms or 4 minutes, not 4 hours.

PMON takes 4 hours to clean up dead sessions? How do you know it takes that long?

Yong Huang

feng_xin

在COMPAQ TRUE 64 环境下

TCP_KEEPIDLE 参数
缺省值是 TCP_KEEPIDLE=14400

我曾做过实验，在client端启动sql*plus，update一条记录，把网线拔掉，锁要等到TCP_KEEPIDLE设定的值才释放。

因为我们一个应用要用到车载终端，经常由于信号问题引起SESSION中断锁无法释放，从而导致应用无法使用。后来改过此参数后锁问题解决。

Yong Huang

最初由 feng_xin 发布
[B]在COMPAQ TRUE 64 环境下

TCP_KEEPIDLE 参数
缺省值是 TCP_KEEPIDLE=14400

我曾做过实验，在client端启动sql*plus，update一条记录，把网线拔掉，锁要等到TCP_KEEPIDLE设定的值才释放。

因为我们一个应用要用到车载终端，经常由于信号问题引起SESSION中断锁无法释放，从而导致应用无法使用。后来改过此参数后锁问题解决。 [/B]

That sounds strange. Disconnecting the network is equivalent to killing your sqlplus process without normal exit. The transaction should be rolled back.

Can someone else do a test? Open a sqlplus session to a database on another host, update a table without commit, disconnect the network cable.

If your observation is indeed true, can you tell us more details possibly with some screen text copied and pasted here? I'm interested to know how tcp_keepalive (called tcp_keepalive_interval on Solaris) affects the disrupted SQL session.

Yong Huang

tonylinux

这些数据是要通你的不稳定链路传回本地的

tonylinux

在你客户端的sqlnet.ora里，单位是分钟，你试试吧，我也不知道行不行