oracle、sql server 预设锁不同行为疑问?
oracle、sql server 预设锁不同行为疑问
为何 oracle 预设更新锁行不排他，其他session还能继续更新，只是排队
sql server 预设更新所行排他，其他session更新会报错
请问是什么设计逻辑导致差异吗?
共有1个答案
Oracle 和 SQL Server 在锁的行为上确实存在差异，这主要是由于它们各自的设计哲学和锁策略的不同。以下是对你问题的简要解释：
Oracle:
Oracle 数据库的锁策略旨在实现高并发性。在 Oracle 中，当一行数据被某个 session 更新时，它首先会获得一个共享锁（share lock），这使得其他 session 仍然可以读取该行，但不能对其进行修改。当该 session 准备提交或回滚其更改时，它会尝试将共享锁升级为排他锁（exclusive lock），此时其他 session 就不能对该行进行任何操作了。
这种策略的好处是多个 session 可以同时读取同一行数据，提高了数据库的并发处理能力。
SQL Server:
相比之下，SQL Server 采用了更为严格的锁策略。当一行数据被某个 session 更新时，它会立即获得一个排他锁，阻止其他 session 对该行进行任何读取或更新操作。这种策略确保了数据的一致性，但可能会降低并发性。
设计逻辑差异:
这两种不同的锁策略反映了 Oracle 和 SQL Server 在数据库设计上的不同侧重点。Oracle 更注重并发性和性能，而 SQL Server 更注重数据的一致性和安全性。因此，在设计数据库系统时，需要根据应用的需求和场景来选择最适合的锁策略。
此外，需要注意的是，Oracle 和 SQL Server 都提供了多种锁模式和选项，可以根据需要进行配置和调整。因此，在实际应用中，需要根据具体的需求和场景来选择合适的锁策略。
-
请任何人解释Oracle中的锁定模式，即共享、独占和更新锁定。我找到了很多关于这个和那个的理论 共享锁:没有人可以改变数据，只读目的 独占锁定：只允许一个用户/连接更改数据。 更新锁:行被锁定，直到用户提交/回滚。 然后，我尝试共享以检查它的工作原理 然后，我发现，用户可以在共享锁定后更改数据。那么，它与独占锁和更新锁有什么不同呢。 另一个问题，更新锁和排他锁有什么不同，即使它们看起来几乎是等同的
-
我不明白的是，当condition_variable和互斥体之间没有任何链接的时候，为什么所有4个线程都可以在互斥体上获得锁？
-
我正在阅读Java中重入锁和同步块之间的比较。我正在浏览互联网上的各种资源。我在同步块上使用Reentrant锁发现的一个缺点是，在上一个中，您必须显式使用try final block来调用final telock在final块中获取的锁上调用解锁方法，因为您的关键代码部分可能会引发异常，并且可能会造成大麻烦， 如果线程没有释放锁，而在后一个中，JVM本身负责在发生异常时释放锁。 我不太相信这个
-
我正在尝试在SqlServer和Oracle上进行批量插入，并在以下测试代码中实现： } 该代码将数据插入到具有主键ID和时间戳的Tester表中。 我想做的是以这样一种方式插入数据库：即使批处理中的一些数据已经存在，也会插入不存在的数据，因为违反了主键约束，所以会抛出BatchUpdateException。 我正在测试一个有50000个条目的批次，其中50%已经在数据库中。 使用SqlServ
-
IBM vs Oracle/Sun JDK，java。util。Timzone表现不同， IBM JDK 1.5与Sun/Oracle JDK 1.6 更新，使用IBM JDK 6测试，它与oracle/sun java-version java version“1.6.0”java（TM）SE Runtime Environment（build pxi3260sr6ifix-20091015\U
-
问题内容： 我一直在尝试查找有关我的查询的问题。该查询实际上是由HQL的hibernate生成的，但是生成的SQL并没有达到我的期望。稍微修改SQL会产生正确的结果，但是我不确定为什么修改会有所不同。 原始查询（不返回任何行） 修改的查询-用逗号替换交叉联接（隐式交叉联接） 返回一行 我的理解可能是错误的，因为写作与Writing相同。所以我不明白为什么查询返回不同的结果。 与导致此问题的第一个查