我的问题是关于DB2 for z / OS ver。 10在可能在重负载下同时发出请求的环境中。
据我所知
CUR_COMMIT = ON DB2配置选项效果是DB2 / zOS中的SELECT查询在相关（关于相同表）未提交的DELETE / INSERT语句的情况下不会被阻止，但阻止对相关未提交的UPDATE的SELECT查询（与DB2 LUW，在未提交UPDATE的情况下也不阻止SELECTs - 因为我在DB2 express版本上验证了自己，并且如果没有阻塞，则立即返回当前提交的数据。
因此，正如文章所建议的那样，如果应用程序使用，仍然可以（在DB2 for z / OS上使用CUR_COMMIT = ON）读取当前提交的数据，而无需等待修改数据的相关SQL语句。只有DELETE / INSERT语句才能修改数据（因此它使用DELETE / INSERT语句而不是UPDATE语句）。
我对大型机和DB2没什么经验，所以我想问一下是不是真的如此，即确实只使用DELETE / INSERT语句保证在提交相关的DELETE / INSERT语句之前我的SELECT都不会被阻塞？
在DB2 for z / OS上使用大型表的情况下，只使用DELETE / INSERT语句是一个可以思考的（即从重载环境中的性能角度来看“非常糟糕的做法”）解决方案行）？