OS与Oracle

竟然写了史上最快，最具可扩展性的文本导出方法, 模仿上一篇的语调，再写个史上最快，最具可扩展性的文本导入方法应该也是挺有趣的一件事情，试试吧，这或许能意想不到地从另一个角度阐述大数据量文本导入的特点，与大数据量文本导出的共性，与大数据量文本导出的不同，Oracle并行技术的运用。
不过，从另一方面讲，大数据量加载应该是一个比较成熟的技术，厚道一点，还是再用一个副标题吧：大数据量加载最佳实践。OK，开始模仿作文……

这个题目有点吓人，不过既然这么说，当然有其强有力的后台做支撑。如果说一句谎言必须用更多的谎言来圆的话，一句真话恐怕也要用更多的真话来阐述，呵呵，且让我慢慢道来。

Oracle上的技术，其实是相当开放的，这里提到的这种文本导出方法，其实在网上已经有人做了很好的论述和实现。只不过本着独乐乐不如众乐乐的想法，在这里再推广一把罢了。

首先明确一点，文本导入到数据库中，或者把数据从数据库中导出为文本格式，这都是极其消耗CPU的操作。所以，导出速度首先取决于系统CPU的运算能力。基于大数据量处理的系统一般都是多节点的RAC系统，于是，文本导出的一个主要议题就是：如何利用起所有RAC节点的所有CPU的运算能力……

一个delete语句，在”同样”的环境下执行两遍。第一次花了16分钟，第二次花了24分钟。
在做delete之前，已经保证表A尽可能一致，两次delete都是以串行方式执行。在这个表上都没有索引存在。整个系统只有这个SQL在运行。
问题究竟出现在哪里呢？

本文要分析的是下面这个SQL，执行了半个多钟头还没返回结果。
Wait events 是了解Oracle运行状态的一个重要途径。对于某个具体的SQL，SQL Monitor Report提供了drill down的方式得到这个具体SQL在运行中的wait events的分布情况，下面是SQL Monitor Report的相应图形。
这里最突出的等待事件是enq: TS – contention，这是关于临时segment的等待事件，这可能是一般的表空间的争用(例如并行直接路径加载数据)，也可能是临时表空间的争用(例如为了hash join或者sort)。那么这时临时表空间的增长状态是怎么样子的呢？SQL Monitor Report提供了这方面的信息……

SQL Monitor Report是11g推出的一个新特性。如果说11gR1里的SQL Monitor Report已经达到可圈可点的程度，那么11gR2里的SQL Monitor Report可以说已经接近完美了。

这个SQL Monitor Report包含的信息比单纯的Execution Plan可全面多了，基本上，有了这份报告之后，troubleshooting所需要的大部分信息都已经具备了。

这个Report主要包括以下五部分……

周末翻阅了以前写在msn space上的文章，不经意间找到了一篇2006年写的关于Linux内核的文章，那时想不到自己会变成一个Database Performance Engineer，不过里面的一些观点却和现在的工作不谋而合，只不过那时面对的Linux Kernel，现在面对的却是Oracle Database……

在做Exadata相关的培训时，Ad-Hoc Query是经常被提及的一个词，中文的翻译应该就叫做随机查询吧，望文生义，就是随机的，不能预料到的查询。但究竟有多随机呢，一些活生生的例子可能更能说明问题。
我们组设计了一个查询，每次show出来的时候，底下总有人暗底里偷笑不止……

有一次跟一个QQ上的朋友一起探讨了另一个对系统CPU进行度量的指标: CPU used by this session。
他刚好有一份AWR报告，在这份报告里，出现了严重的CPU used by this session和DB CPU不一致的现象……

构建DSS系统的第一步离不开数据加载，通过文本文件加载是最常见的方式，Oracle提供了外部表加载的方法，即把一个文本文件当成一个正常的表来进行操作，通过类似insert /*+ append */ into table select from external_table的方式进行加载。
数据加载是一个CPU-Bound的过程，不过是通过什么工具，external table也好，sqlldr也好，imp也好，impdp也好。
这个过程的AWR报告会是怎么样子的呢……

如何得到系统大致的MBPS呢？
MBPS= (Physical reads + Physical writes) * Block_Size = (196,271.4+2.0)*8*1024/1024/1024 = 1533 MB/s
更准确的MBPS可以从Instance Activity Stats部分获得……