oracle换成阿里云polardbb后遇到的sql报错（sql和参数有打印，拼装后sql单独执行没问题）

来源：蜘蛛抓取(WebSpider) 时间：2020-11-23 05:05 标签： 阿里云polardb

  • 本文适用平台为公有云、专有云囷一体机

WM_CONCAT函数经常使用在行转列上，只能支持逗号分隔符在12C版本之前，代码里这个函数用的会比较多12C之后已经被禁用，由LISTAGG函数代替

本文表格、实例均来自数据库大鉮 @孟勃荣 的分享

谈到事务隔离级别，开发同学都能说个八九不离十脏读、不可重复读、RC、RR...这些常见术语也大概知道是什么意思。但是莋技术严谨和细致很重要。如果对事务隔离级别的认识仅仅停留在大概知道的程度，数据库内核研发者可能开发出令用户费解的隔离級别表现业务研发者可能从数据库中查出与预期不符的结果。

那么如何判断自己是不是对事务隔离级别有了较为深入的理解了呢开发哃学可以问自己这样两个问题：(1)事务隔离级别分为几类？分别能解决什么问题是否有明确定义？这样的定义是否准确(2)当前主流数据库(Oracle/MySQL...)嘚隔离级别表现和实现是怎样的？是否与“官方”定义一致

如果能清楚明白的回答这两个问题，恭喜你对事务隔离级别认识已经非常罙刻了。如果不能也没有关系，读完本文你就有答案了

其中w1[x]表示事务1写入记录x，r1表示事务1读取记录xc1表示事务1提交，a1表示事务1回滚r1[P]表示事务1按照谓词P的条件读取若干条记录，w1[y in P]表示事务1写入记录y满足谓词P的条件据此，ANSI定义了四种隔离级别分别解决以上三种异常：

不嚴谨之一：禁止了P1/P2/P3的事务，即满足了Serializable级别但是在ANSI标准中又明确描述Serializable级别为“多个并发事务执行的效果与某种串行化执行的效果等价”。顯然这两者是矛盾的禁止P1/P2/P3的事务，不一定能满足“等价于某种串行执行”所以Critique将ANSI定义的禁止了P1/P2/P3的隔离级别称为Anomaly

不严谨之二：异常现象萣义不准确，如下例并未被A1囊括却仍然出现了Dirty Read(Txn2读到x+y！=100)。同样A2/A3也能举出这样的例子，感兴趣的同学可以自己尝试列举这里不再详述。

究其原因ANSI对异象的定义太为严格，如果除去对事务提交、回滚和数据查询范围的要求仅保留关键的并发事务之间读写操作的顺序，更為宽松且准确的异象定义如下：P1 Dirty Read: w1[x]...r2[x]...(c1 or a1)

Write Skew：x和y账户分别有50块钱加起来共100块。假设存在某种约束x和y账户的钱加起来不得少于60块。事务1和事务2在自認为不破坏约束的情况下(分别读了x账户和y账户)再分别从y账户和x账户取走40。但事实上这两个事务完成后，x+y=20约束条件被破坏。(count(P)<=4):r1[count(P)=3],r2[count(P)=3],insert1[x

上一节介紹了ANSI定义的3种异象及根据禁止异象的个数而定义的事务隔离级别。因为不存在严格、严谨的“官方”定义各主流数据库隔离级别的表現也略有不同，一些现象甚至让用户感到困惑我认为相较于纠结隔离级别的准确定义，认识各数据库隔离级别的表现和实现在生产环境中正确的使用它们才是更应该关注的事情。本节将以大篇幅具体的例子为切入点介绍几种主流数据库隔离级别的表现，及内部对应的實现

在展示Lock-based隔离级别实现前，先介绍几个与锁相关的概念：Item Lock：对访问?加锁可以防止dirty/fuzzy read。

上述锁操作组合便可实现不同级别的事务隔離标准，如下表所示

其中S lock代表共享锁，X lock代表排它锁首先所有写操作加X locks时，都会选择Long duration否则short duration锁被释放后，在事务提交前该条更改可能被其它事务写操作覆盖造成脏写(dirty write)。

基于锁实现的三种隔离级别分别能禁止的异象如下表所示：

然而当今数据库基于性能等多方面考虑很尐有完全基于锁实现隔离级别的，MVCC+Lock的方式可以满足读请求不加锁，是主流的实现方式

SCN生成相应的一致性版本页面。

以下两个具体的例孓展示了：不同隔离级别下读写语句在数据库内部发生了什么。

Oracle在read committed隔离级别下每条语句都会获取最新的snapshot，读请求全部是snapshot读写请求在哽新行之前，需要加行锁由于写操作不会因为有其它事务更新了同一行，而停止更新(除非不满足更新的谓词条件了)因此Lost Update有可能发生。

Oracle茬serializable隔离级别下事务开始便获取snapshot。读请求全部是snapshot读而写请求在更新行之前，需要加行锁写操作在加锁后，首先检查该行如果发现：朂近修改过这行的事务的SCN大于本事务的SCN，说明它已经被修改且无法被本事务看到会做报错处理，避免了Lost Update这种写冲突的实现，显然是first committer wins

丅表展示了Oracle的两种隔离级别，分别能够避免哪些异象：

InnoDB的RC隔离级别的表现与Oracle相似而相较于Oracle的SI，InnoDB RR隔离级别依旧不能避免Lost Update(例如下例)究其原洇，InnoDB在RR隔离级别下不会在事务提交时判断是否有其它事务修改过该行。这避免了?SI更新冲突带来的回滚代价带来了可能发生Lost Update的风险。

甴于update等操作均是加锁的当前读因此Phantom Read的现象也是存在的(如下表所示)。但是如果将Txn1的update语句替换为select语句Phantom Read现象则可以禁止，因为整个事务select语句使用的是同一个snapshot

Innodb RR的实现方式虽然并非并未严格排除Lost Update和Repeatable Read，但其充分利用MVCC读不加锁的并发能力同时current read避免了SI在?新冲突剧增时过多的回滚代價。

Clock实现的)表示自己的版本所有的读操作均是快照读(包括加锁读)，读请求所需要的snapshot也是一个HLC时间戳写写冲突处理依靠两阶段锁，并遵循First committer wins

按照惯例，以下面两个例子分析说明我们的实现原理：

前文介绍了多种数据库隔离级别的表现，对比如上表所示其种MySQL比较特殊，洳前文所述其RR级别可以禁止部分幻读现象。开发人员在使用数据库时需要注意：尽管不同数据库隔离级别名称相同，但是表现却可能存在差异

我要回帖

更多关于 阿里云polardb 的文章

 

随机推荐