之前曾提到如何利用SQL Monitor Report对SQL进行诊断与调优,对于具体的SQL调优而言,SQL Monitor Report提供的信息无疑比AWR更有针对性,当然,AWR在信息的全面性方面会更胜一筹。本文提供一个具体的例子,同样的SQL,同样的执行计划,第一次执行的时间远远大于第二次执行的时间……
|
||||||
|
之前曾提到如何利用SQL Monitor Report对SQL进行诊断与调优,对于具体的SQL调优而言,SQL Monitor Report提供的信息无疑比AWR更有针对性,当然,AWR在信息的全面性方面会更胜一筹。本文提供一个具体的例子,同样的SQL,同样的执行计划,第一次执行的时间远远大于第二次执行的时间…… 关于Cell Flash Cache,或许大家都余兴未尽,例如: 既然提到了Flash Cache,如果不提下对OLTP的提速好象会缺少点什么。对OLTP系统而言,缓存是一个极其重要的设计,不管是数据库节点上的内存上的Buffer Cache,还是存贮节点上的Flash Cache(Exadata),还有数据库节点上的Flash Cache(某些平台,如Linux)…… 准备写一系列的文章,专门分析下Exadata的架构。时间真过得很快,自从Exadata问世以来,一直围绕着它做各种各样的性能测试,从V1过渡到V2。Exadata在大踏步地前进着,我总认为,这应该是一个很优秀的产品,而我也相信时间会证明这一点的。 竟然写了史上最快,最具可扩展性的文本导出方法, 模仿上一篇的语调,再写个史上最快,最具可扩展性的文本导入方法应该也是挺有趣的一件事情,试试吧,这或许能意想不到地从另一个角度阐述大数据量文本导入的特点,与大数据量文本导出的共性,与大数据量文本导出的不同,Oracle并行技术的运用。 这个题目有点吓人,不过既然这么说,当然有其强有力的后台做支撑。如果说一句谎言必须用更多的谎言来圆的话,一句真话恐怕也要用更多的真话来阐述,呵呵,且让我慢慢道来。 Oracle上的技术,其实是相当开放的,这里提到的这种文本导出方法,其实在网上已经有人做了很好的论述和实现。只不过本着独乐乐不如众乐乐的想法,在这里再推广一把罢了。 首先明确一点,文本导入到数据库中,或者把数据从数据库中导出为文本格式,这都是极其消耗CPU的操作。所以,导出速度首先取决于系统CPU的运算能力。基于大数据量处理的系统一般都是多节点的RAC系统,于是,文本导出的一个主要议题就是:如何利用起所有RAC节点的所有CPU的运算能力…… 本文要分析的是下面这个SQL,执行了半个多钟头还没返回结果。 随着业务的发展,IT部门的服务器数量会越来越庞大,另一方面,这些服务器的利用率却得不到充分利用,于是,服务器的资源整合就被提上了议事日程,这方面的相应的解决方案一般有 在做Exadata相关的培训时,Ad-Hoc Query是经常被提及的一个词,中文的翻译应该就叫做随机查询吧,望文生义,就是随机的,不能预料到的查询。但究竟有多随机呢,一些活生生的例子可能更能说明问题。 构建DSS系统的第一步离不开数据加载,通过文本文件加载是最常见的方式,Oracle提供了外部表加载的方法,即把一个文本文件当成一个正常的表来进行操作,通过类似insert /*+ append */ into table select from external_table的方式进行加载。 |
||||||
|
Copyright © 2012 OS与Oracle - All Rights Reserved |
||||||
最近评论