ITPub博客

由浅入深，介绍了数据库中常见而又关键的概念，了解数据库思路以及工程实现中需要注意的事项。

进入互联网时代，你的绝大部分操作都可以在网上进行，极大的方便了我们的生活。但是信用卡盗刷者也可以利用网络来诈骗，典型的做法是：诈骗者首先入侵安全级别较低系统来盗窃信用卡卡号，用盗得的信用卡进行很小额度的消费进行测试，如果测试消费成功，那么他们就会用这个信用卡进行大笔消费，来购买那些可以倒卖的财物，实现诈骗敛财的目标。大部分银行都有针对信用卡诈骗的反欺诈检测系统，通过对诈骗模式进行识别，及时通知用户

在这个关于直方图的简短系列中，我们将讨论为什么需要直方图以及Oracle创建它们的方法。我们将评估创建它们的成本以及给我们带来不必要的问题，然后我们将检查它在您的执行计划中给您带来潜在的问题。这篇文章的概述将局限于12c之前的Oracle版本，其中出现了在减少开销和提高稳定性的新型直方图和收集方法。

在这个系列的第5部分，我们看了一些需要额外注意的”第一个子操作先执行”的例子。在第6部分中，我们将继续探讨一个原则—“子查询推入”，其中“第一个子操作先执行”可能会导致错误的结论。

我提出了“子操作按先后顺序执行，递归向下”的解释执行计划的基本策略，但是这并不是一个完美的规则，即使遵循基本的“子操作按先后顺序执行”，也很容易对执行过程中发生的事情产生错误判断。在这部分中，我们将看到几个例子，其中我们仍将在某些情况下使用“子操作按先后顺序执行”，一个BUG的例子使规则看起来是错误的，还有一个示例不适用“子操作按先后顺序执行”。实际上，有几种不同的情况并不适用该规则，但是我们必须

在第3部分（引用沃趣科技——执行计划-3：解释规则），我们用一个简单的hash join介绍了阅读执行计划最基本的规则---”子操作按先后顺序执行，递归向下“。这让我们了解查询中Oracle生成rowsource的顺序和访问中不同物理对象的顺序（隐式的）。这个系列的开头，我就强调过规则不是适用于所有的场景，下一部分（第5部分）里我们会来看几个我们需要特别注意的场景。但是在这部分中，我们将继续使用更

Oracle Database Performance Tuning GuideOracle数据库中我们分析一个会话或SQL执行时间效率或者分析解释导致会话等待的原因的一个很重要的方法是分析它花费的时间构成。在Oracle RAC中，Oracle使用不同的等待事件时间来表示不同的请求结果及时间消耗。例如，当一个会话上实例正在寻找全局缓存中的块，它不知道它是否

根据前面系列的文章的解释，我们知道PCM资源的Master节点是通过hash算法得出。那么在一个多节点的RAC集群中，数据块请求节点和存放它的相关锁元素信息节点有很大概率是不相同的。这就意味着用户对资源的请求会存在很多的2或3次回路，从而造成很多的消息通信增加私网的负载进而影响影响数据库的性能。为了缓解这种性能影响，Oracle使用资源的remaster来减少资源的跨节点请求。针对某一个数据库对象

PCM锁资源存储方式有两种，1.如果PCM锁属于本地实例，那么它会被存储在本地实例的LE结构中。2.如果PCM锁属于远程实例那么它将会被分配存储在本地实例的共享池中。kclle结构：    kcllerls表示release;     kcllelnm表示 name（id1，id2）;    kcllemode表示 hold-m

在这系列的前两个部分中，我们列举了一些生成或者找回执行计划的方法，也学习了一些额外的步骤可以帮助我们模拟真实的环境来判断执行计划是否存在问题。这部分我们会熟悉整体解释执行计划的基本准则。在第四部分前，我们不用考虑使用谓词的部分。The Shape of a plan我们会从一个简单的例子开始-创建几张表，连接它们，在我们检查执行计划的时候需要回答提出的问题。这里是数据

一致性读请求  ktrget请求调用流程，调用kcbgtcr获取最佳缓存区域用以构建CR缓冲区，然后调用ktrgcm应用undo构建可用的CR缓存。kcbgtcr计算扫描hash桶，调用ktrexf查找最佳缓存区。如果在缓存区域在本地则结束，如果不在本地则调用kcbzib获得缓存区域。kcbzib请求调用kcbzgb获得一个buffer并且设置buffer的状态为Reading

在Part 1中我们了解了两种获取执行计划的方式，第一种是优化器预测它将会怎么执行，通过以下方法查询获取：explain plan for {sql statement} select * from table(dbms_xplan.display);第二种是优化器在我们执行语句后真正的执行路径，通过以下方法查询获取：set&

看懂执行计划是作为处理数据库性能问题的必备技能之一，接下来一系列的文章我会告诉你怎么去做。我们会从一些文章开始讨论几种获取执行计划的方法，并且评估不同来源的执行计划最适合哪种场景。完成上述的内容后我们会继续深入解释简单执行计划的基础，之后会介绍一个用来解释大部分执行计划的规则-需要小心使用该规则。同时也会重点说明因为优化器改写我们的SQL导致执行计划与预期的不符的情况。一些规则外的异常不可避免，所

在本系列的前一期文章中，我制作了一些图，突出显示了按表扫描执行大量删除操作和按索引范围扫描执行大量删除之间的主要区别。根据所涉及的数据模式，选择正确的策略可能对随机I/Os的数量、生成的undo的数量和排序所需的CPU数量产生显著影响——所有这些都可能影响执行删除所需的时间。然而，这个简单的演示跟生产环境当中相比，生产环境当中这个情况更为复杂。所以，如果你面临着一项艰巨的任务，你需要仔细考虑如何对

在本系列的上一部分中，我们研究了在大数据删除表和索引和案例。在这一部分中，我们将继续讨论不同案例所隐含的工作量，然后考虑删除策略，或者需要制定减少工作量的策略。基本开销部分除了时间本身，我们还要关注其它三个指标，即大数据删除的过程中：生成的undo和生成的redo以及发生的I/ O量。这些因素并不是相互独立的，这在优化删除的一般性讨论中引入了很多复杂性，并且删除操作本身可能会影响同时运行的其他会话

在这个简短系列的第1部分中，我提供了两个场景的非正式描述，在这些场景中，我们可以从表中进行大规模删除。没有一个具体的例子,很难想象删除数据的性质和可用的访问路径会产生大数据量删除操作对系统的性能影响,所以我要把大部分的时间花在本文讨论的两个测试生成的数据集。这篇文章似乎有点长但相当多的空间会被表格占用。简单的数据集随着硬件的能力和规模的不断增长，我们越来越难以就“大表”或“大规模删除”的含义达成一

Oracle RAC CR Server Part One

我们为什么要删除大量的数据？我们是否知道在删除操作完成后我们又需要如何验证我们是否到达最终目标？我们可以使用哪些方法来最小化的执行删除所带来的影响以及删除完成之后我们还需要做什么才能达到最终的目标？

前面的章节我们介绍了Oracle为实现Cache Fusion引入的各种改变和新的概念。本节我们从RAC环境中可能发生的场景对Oracle Cache Fusion的实现进行更近一步的探讨。

Oracle RAC Enqueues And Lock Part 3（Deadlock）