Archive for the 'Oracle RDBMS' Category

Aug 25 2008

OCM exam guide - Prepair

Published by kamus under Oracle RDBMS

今天开始在OU参加为期四天的Oracle 10g OCM考试的培训,这个培训是第一次在OU举办,并不是对OCM中牵涉到Oracle数据库技术进行培训而是专门针对如何应对OCM考试的培训。

OCM考试全称为Oracle Certified Master(Oracle认证大师),是在OCA(Oracle认证专员Oracle Certified Associate)、OCP(Oracle认证专家Oracle Certified Professional)之后更高一级的Oracle技术认证,也是Oracle技术认证最高的一个级别。

考试是两天的时间,全部为实际操作的考试,第一天是创建数据库和安装Grid Control,第二天是创建RAC以及部署Data Guard,其中穿插着几乎所有Oracle数据库管理需要用到的常用知识。

其实,技术上来说OCM的考试并不很难,考试涉及的内容也是很喜闻乐见的技术架构。但是问题就在于时间,一个数据库管理员用dbca这样的图形化界面在一个小时里面创建完一个数据库这基本上没有难度,但是要求你不能使用图形界面只能用命令行方式呢?你能记得所有create database的语法吗?你能记得所有storage参数的语法吗?你能记得设定ASSM属性那个四个单词的前后顺序吗?

也许有人会说,我不需要记得啊,我有Oracle Online Documentation可以查询哦,是的,没错,OCM考试允许你查询Oracle的联机帮助文档(仅仅限于联机文档而不允许使用internet去做搜索),但是你能在几分钟内定位到你想要找的内容呢?又一共有多少个知识点你需要去查文档呢?而两个小时的考试时间又允许你去查多少次联机文档呢?我个人认为我对联机文档已经颇为熟悉了,但是今天上午的经验让我必须承认,如果我不继续加以练习,我绝对无法在规定时间内创建出完全符合考试要求的数据库。而如果第一天上午考试结束的时候你没有创建出需要的数据库,那么这次OCM考试你就失败了,因为后面考试的内容是要使用到这个数据库的。

最后,只要是考试就会有压力,当时间一点一滴流逝的时候,你能确保自己在最后的半小时里面还能像刚开始考试时候那样冷静吗?本来一次就能输入正确的SQL语句,会不会就要多输错几个单词,多按几次Delete键,多看到几次ORA报错信息才能完成输入呢?

好吧,这一系列文章的目的并不是给大家施加压力,而是准备告诉大家如何应对OCM考试,这几乎已经无关乎技术,而更多的是技巧了。

1. 保持平常心和信心,这很重要,当然也要意识到信心是通过考试前多次的自我实验而逐渐累积出来的。

2. 请一定在坐到考试桌前之后,尽快检查你面前的机器,会是两台RHEL4的Linux服务器,Gnome的图形界面(喜欢用KDE的兄弟们请去熟悉一下Gnome的操作),有鼠标有键盘,检查你的键盘输入是否顺畅,检查你的鼠标移动是否顺畅,检查机器的电源插座是否插牢,检查Oracle 10gR2的软件是否已经安装,检查$ORACLE_HOME等环境参数是否已经设置好,检查联机文档是否可以正常读取。按照常理来说,这些都不应该出问题,但是万一你运气好碰到有问题的机器,一旦考试开始计时,那损失的就只能是你自己了。哦,为什么是两台机器呢?因为一台是用来创建数据库,而另外一台是用来安装Grid Control的OMS。

下面一篇文章开始正式介绍,如何快速使用命令行方式创建一个数据库,再次强调,这无关乎技术,不是告诉你create database的语法该怎么写。

4 responses so far

Aug 08 2008

We simply don’t need them anymore!

Published by kamus under Oracle RDBMS, Apps

Oracle SQL Developer

之前作为一个Oracle Employee,却总是在使用PL/SQL Developer(而且是破解版),这实在有些说不过去,但是如何找到一个合心趁手的能够在有条件的情况下比SQL*PLUS更方便的工具却实在不是一件简单的事情,以前期待tora被Quest收购以后会有长足发展,可惜,并没有看到最终的结果。

之前曾经说过,PL/SQL Developer对于我最难以割舍的是completion insight功能,当你记不住表、性能视图或者存储过程、函数的全名,PL/SQL Developer将会在你输入了几个字母之后自动提示。TOAD发展了那么多年,却一直没有提供相类似的功能。

但是现在完全免费的替代产品出现了,这就是Oracle SQL Developer,Oracle官方出品的开发工具,当然这个工具并不是今年才推出的,现在最新版本已经是1.5.1.54.40,但是,最早的1.0版本并不是那么好用,而现在,我可以郑重地推荐它了。

请注意,这个工具是完全免费的,可以通过这个链接下载。

以一个普通使用者(甚至说是一个并不是着重在开发上的数据库管理员)的身份比较一下Oracle SQL Developer和PL/SQL Developer。

1. 格式化的结果输出。
这一点任何一个第三方工具都做得不错,是一个基本功能。

2. 自动提示。
也就是上面提到的Completion Insight功能,可以说,Oracle SQL Developer拥有的功能以及速度绝对不亚于PL/SQL Developer,甚至有更人性化的表现。比如当你键入select * from,空格之后,Oracle SQL Developer会立刻给出一个当前用户下的所有Table的列表,如果继续键入比如DBA三个字母,那么列表将转换为DBA打头的所有数据字典。而如果你从一行的开头键入exec四个字母,那么当回车以后,Oracle SQL Developer会立刻给出一份所有可以执行的存储过程的列表。
最新版本中对于V$视图的提示有bug,相信很快就可以修改。

3. 代码美化功能。
所有使用过PL/SQL Developer的朋友们应该都知道在最近这几版中都有一个PL/SQL Beautifier的功能,可以将一大串SQL语句格式化更容易阅读的样式。同样Oracle SQL Developer也提供了这样的功能,称之为Format,快捷键是Ctrl+F7。

4. 显示SQL的执行计划。
在Oracle SQL Developer中快捷键是F6,同时也提供了显示Autotrace的结果,快捷键是F10(最新版本中似乎有点儿小bug,有时候需要按两次F10才能显示)

5. 会话监控。
在PL/SQL Developer中我们可以显示当前数据库中的所有会话,点击某一个会话,在下方会显示该会话正在执行的SQL,正在经历的等待事件以及其它一些可以自定义的感兴趣的信息,Oracle SQL Developer同样提供了这个功能,可以在Tools -> Monitor Sessions菜单中找到它。

6. 快捷显示对象信息。
比如写了一条SQL语句,其中牵涉到一张表,我们可能会想立刻看到这张表有哪些字段,这张表上有哪些约束哪些索引,如果是分区表有哪些分区,在PL/SQL Developer中我们会选中SQL语句中这张表的名字,然后右键 -> View,同样Oracle SQL Developer也提供了这个功能,同样可以鼠标右键选中表名 -> Popup Describe,另外还有快捷键Shift+F4。

7. 编写以及调试存储过程。
我并不有太多的机会去编写一个很长的存储过程,因此这点我不敢对PL/SQL Developer和Oracle SQL Developer做过多的比较,但是我知道好几个版本的PL/SQL Developer(包括最新版)在编译存储过程的某些特定语句的时候会导致ORA-600错误,而在SQL*Plus里面直接编译则完全没有问题,很多客户出现了这个问题寻求我们的帮助,而我们的回答是,抱歉,这是PL/SQL Developer的问题我们不做技术支持,但是如果你要是改用了Oracle SQL Developer呢?恭喜你,虽然这是个免费的产品,但是仍然可以得到原厂商的技术支持。

好吧,具有了上述这些功能,至少对于我来说,Oracle SQL Developer已经完全具备了日常管理数据库的所有需要点,而且用起来一点儿也不觉得别扭,只是可能快捷键的改变需要适应一下。比如在PL/SQL Developer中执行一个SQL是F8,而Oracle SQL Developer则是F9,显示执行计划一个是F5而另外一个是F6,但是这都是小问题,不是吗?要知道人生总是在不断变化的,呵呵。

接下来是Oracle SQL Developer的闪光点,这些闪光点会让Oracle SQL Developer更加可爱。

1. 自动更新。
Help -> Check for updates,将会自动将Oracle SQL Developer更新到最新的版本,包括多种插件。

2. 插件。
这是多么令人兴奋的功能,要知道,在浏览器领域的Firefox,在Java开发工具领域的Eclipse,都是因为支持插件(或者称之为扩展)体系,并且有大量丰富的插件才成为了焕然一新的工具,噢,我知道PL/SQL Developer也是支持Plugins的,但是这么多年了,Plugins始终只有那几个。而Oracle SQL Developer才推出多久,我们已经可以看到像Fourth Elephant的Insider这样强大的扩展了,Insider一眼看上去简直就是一个Quest Spotlight for Oracle,虽然我对这个插件不是那么感兴趣,但是你得承认它确实很强大。

3. 跨平台。
PL/SQL Developer只能在Windows上使用,而Oracle SQL Developer目前已经支持了Windows,Mac OS X,Linux,这得益于Java的跨平台特性,好吧,我承认Java用于桌面应用确实速度有些让人不满意,但是对于Oracle SQL Developer来说,仅仅是启动速度有些慢而已,实际使用中仍然是行云流水的。而且得益于依靠Java,Oracle SQL Developer连接数据库,并不需要安装Oracle数据库客户端,这确实很方便。

4. Reports。
一个新安装的Oracle SQL Developer就已经包含了一个Reports标签页,内置了一部分可以用于数据库管理的脚本,并且可以允许使用者自定义自己需要日常使用的脚本,而且支持复杂的父子视图效果,就是类似于Session Viewer的效果,点击父结果中的某一行,能够将更详细的关联信息显示在子结果中。每个DBA都有自己积累的一套SQL,你可以将它们全部放在Oracle SQL Developer中。

5. 多连接。
在同一个Oracle SQL Developer界面里,可以连接多个数据库实例,虽然这不是什么复杂的功能,但是,PL/SQL Developer却做不到。

6. tkprof直观显示。
用Oracle SQL Developer直接打开一个trc文件,将会出现一个图形化的界面,并且包含了几乎所有的tkprof功能,比如可以按照某个指标进行排序。

7. 免费。
有什么东西比免费更吸引人呢?曾经在itpub上做过一个投票调查,目前使用PL/SQL Developer的Oracle DBA或者开发人员占据了超过60%,而其中绝大部分都在使用破解版。改为Oracle SQL Developer吧,你不用再去辛辛苦苦找最新的破解,你也可以自豪地说我现在用的开发工具是Free的,是正版的。

好吧,我承认Oracle SQL Developer是一个新产品,在很多小功能上确实还没有像PL/SQL Developer那样丰富。比如说也许我们需要一个command window,一个类似于SQL*Plus的界面,可以输入诸如archive log list或者show sga这样的命令,也可以仅仅输入edit 表名就可以弹出更改表结构的界面,输入edit 存储过程名就可以弹出编辑存储过程的界面;也许我们需要一个text import工具,可以方便地通过图形化界面将一个csv文件中的记录插入到一个表中;也许我们需要一个data gernerater工具可以方便地生成测试数据。

但是,这些都是小事儿,没有也就没有吧。另外,请相信Oracle的研发实力,短短的一年时间,Oracle SQL Developer已经开始引人瞩目了,而且Oracle一直在大力地研发这个工具在频繁地发布新版本,所以也许不久的将来这个工具将更好更强大。在这里可以看到大量使用者提出的Feature Request,很多已经被接收,将会出现在下一个版本中。

这篇文章不是一个正规的Oracle SQL Developer的产品功能或者说使用介绍,这仅仅是因为我作为一个普通的Oracle数据库顾问发现了一个免费的好用的工具(只不过恰巧这个工具是Oracle推出的而已)而感到欣喜之后的随意而为的文章,我很期待与已经在使用Oracle SQL Developer和看到这篇文章转而使用它的各位做更多的经验交流。

用一个使用者的感想做结,这个感想在Oracle SQL Developer的主页上也可以找到。

We’ve given up all of our licenses for other tools. We simply don’t need them anymore. Oracle SQL Developer does it all for us. We’ve saved a lot of money because it’s free. It’s also given our development staff a standard tool and they love it. It’s made training and support easier.

更多的讨论请参看在ITPUB中的专题贴

10 responses so far

Jul 18 2008

Why VKTM background process in Oracle 11g

Published by kamus under Oracle RDBMS

在Oracle11g中,我们可以发现一个新的基础后台进程叫做VKTM (virtual keeper of time),这个进程是必须存在的。

在数据库启动时候的告警日志中可以看到:
VKTM started with pid=3, OS id=2256 at elevated priority
VKTM running at (20)ms precision

在数据字典中也可以查询到如下信息:

  1. SQL> select name,description  from v$bgprocess where name='VKTM';
  2.  
  3. NAME  DESCRIPTION
  4. ----- -----------------------------------------
  5. VKTM  Virtual Keeper of TiMe process

阅读Concepts文档可以看到对这个后台进程的解释是:

VKTM (virtual keeper of time) is responsible for providing a wall-clock time (updated every second) and reference-time counter (updated every 20 ms and available only when running at elevated priority).

我想这个解释仍然不足以描述这个进程到底是做什么的。

好吧,那这个进程到底是做什么的?

在11g之前所有的Oracle数据库后台或者前台进程如果需要获得当前时间信息,就需要调用操作系统的gettimeofday()函数或者说是相类似的函数。而VKTM进程就是专门用来获得时间信息然后将信息存放在SGA中供其它进程使用,这样其它进程当需要时间信息的时候,只要到SGA的某个内存位置去获得就好,而不用频繁调用gettimeofday()函数。毫无疑问,这样效率会更高。

在RAC测试中,Oracle 1.1.0.6版本LMSx进程获取时间信息时,可以从VKTM进程中获益大概70%的速度提升,而11.1.0.7将会更高。

同时,因为gettimeofday()函数也引发了很多bug,所以无论是RAC还是NORAC库,都将从VKTM进程中获益。

6 responses so far

Jun 20 2008

Execution Plan!

Published by kamus under Oracle RDBMS

今天客户做系统升级,从原先的Oracle 8.1.7.4升级为Oracle 9.2.0.8 RAC,并且将应用系统从1.1版本升级为2.0版本,是一个很大的举动。

其中牵涉到数据转换,软件开发商用简单的insert into xxx select … from yyy@dblink a, zzz b where a.ccc=b.ccc这样的语句完成数据转换,之前已经在测试环境中多次运行过,但是今天却仍然发生了问题,本来在测试环境中只需要运行100秒的转换过程在生产环境中运行了将近1个小时也没有结束,因为转换过程是大量顺序执行的insert语句,因此其中一个语句堵塞了,下面的语句也无法运行。

包括客户、软件开发商在内的十数人站在身后,为什么测试环境中运行如此快的SQL在产品环境中变得如此缓慢?该如何解决?如果在已经严格计算过的时间窗口内无法解决,是否需要回退整个升级工作?情况看上去很紧急。

因为牵涉到dblink,因此检查网络,没有发现问题。

让软件开发商在测试环境中重新跑这个SQL,速度仍然很快,检查执行计划,发现在测试环境中是Full table scan + Hash Join,而生产环境中却是Index range scan + Merge Join,检查互相Join的表,一个只有几千条记录,一个有几十万,很明显Hash Join应该是明智的选择。

没有时间去检查为什么产品环境中Oracle选择了更差的执行计划,加Hint先去解决问题。

添加了/*+USE_HASH(C,B) ORDERED*/提示,重新检查执行计划,已经是想要的Hash Join了,再次执行SQL,40多秒就完成了数据转换。

不同的执行计划差异就是如此之大,CBO任重道远。

Update@2008-6-20

今天主要任务是检查为什么相同SQL的执行计划在不同的机器上会不一样。通过10053 trace看到的区别。

生产环境中:
***********************
Table stats Table: XXX Alias: D
TOTAL :: CDN: 0 NBLKS: 1 AVG_ROW_LEN: 0

测试环境中:
***********************
Table stats Table: XXX Alias: D
TOTAL :: (NOT ANALYZED) CDN: 2893269 NBLKS: 35422 AVG_ROW_LEN: 100

很明显,生产环境中认为这张表是0条记录,但是在测试环境中因为没有做过表分析,Oracle选择了2893269条记录作为猜测值。这就是导致执行计划差异巨大的真正原因。

询问软件开发商的工程师,确实之前的多次测试中,在数据转换之前都没有做表分析,而这次生产环境却做了表分析,XXX表中的数据是在数据转换过程中才插入的,而数据转换之前做的表分析则告诉Oracle这张表中没有数据(实际上却有超过120万条记录)。

这次的故障告诉我们:
1. 表分析不要随便做,做错了比不做还差。
2. 当有人告诉你,“没有任何差别啊、所有的步骤都是一模一样的啊”,不要相信。问题的产生一定有原因。

5 responses so far

Page 2 of 24«12345»...Last »