Tag Archives: DBA

Revoke 权限后出现的无效对象该如何编译

以前写过一则 Blog , 如何重编译无效的数据库对象. 可是有的时候,因为一些原因,在对一些数据库的 Package 对象的权限做修改之后, 会出现大量的无效对象, 即使反复编译,也是无济于事的.
今天就遇到过一起.

ops$oracle@demo>select object_name,owner,object_type
from dba_objects where  status='INVALID';
OBJECT_NAME OWNER OBJECT_TYPE ---------------------------- -------------------------- ------------------ DRIDDLR CTXSYS PACKAGE BODY
ops$oracle@demo>alter package ctxsys.DRIDDLR compile body;
Warning: Package Body altered with compilation errors. ops$oracle@demo>execute utl_recomp.recomp_serial('CTXSYS'); PL/SQL procedure successfully completed.
ops$oracle@APAYCA>select object_name,owner,object_type
from dba_objects where status='INVALID';
OBJECT_NAME OWNER OBJECT_TYPE ---------------------------- -------------------------- ------------------ DRIDDLR CTXSYS PACKAGE BODY

因为刚刚撤销了 Public 对 DBMS_METADATA 和 DBMS_JOB 的执行权限. 本着最小权限授予原则,所以决定尝试恢复 CTXSYS 对两个包的执行权限.经过测试,

SQL> grant execute on  DBMS_JOB to ctxsys; 

然后重新编译,成功.

继续阅读

墨菲定律与 DBA

今天参加培训的时候胡思乱想,忽然间想起来墨菲定律(Murphy’s Law)这个有趣的话题. 西方文化中,有很多所谓的”定律”, 墨菲定律应该算是一则比较著名的”定律”了.什么是墨菲定律? 最简单的表达形式是”有可能出错的事情,就会出错(Anything that can go wrong will go wrong)”。
爱德华·墨菲、约翰·保罗·斯特拉普和乔治·尼克斯凭这条定律居然还得到了搞笑诺贝尔奖(IgNobel)奖。而墨菲定律的一些衍生版本也的确有趣.比如”东西久久都派不上用场,就可以丢掉;东西一丢掉,往往就必须要用它”,再比如”你出去买爆米花的时候,银幕上偏偏就出现了精采镜头”.
抛开 Murphy’s Law 衍生出来如此多的版本不谈,说一下墨菲定律和 DBA 之间的关系。Anything that can go wrong will go wrong, 这句话对 DBA 来说,应该是引起注意的, 甚至作为金科玉律也不为过,一般来说,没有哪一个人管理的数据库是完美无缺的,但是如果你发现了数据库的缺限置之不理,存在侥幸心理,那么最后往往会发生你最担心的问题。我就曾经亲生经历过几起类似的事件,事后总结的时候想 “如果我…如何做” 就好了. 但是已经发生的事情就不允许假设了.

继续阅读

招聘信息及求职建议

注意到年后是不少 DBA 朋友找工作的时候, 干脆做一个页面把一个猎头招聘信息贴出来,方便一下那些求职的朋友.
职位列表:

在此之前的一个月内,已经替公司找到了一个不错的 DBA .上一个招聘信息还是有点价值的.这段时间也收到了不少朋友的简历.这里对那些求职的搞技术的朋友们一点小小的建议(主要针对 DBA):
简历应该有针对性.很多朋友对简历似乎都不怎么上心.很大一部分朋友都是直接用那些招聘站点的简历模板,也不修改就直接发出来.应聘产品 DBA 也是这个简历,应聘开发 DBA 也是这个简历.我的建议是,每一份简历最好有针对所应聘的职位有具体的能力描述,没错,定制后的内容,同时把那些不必要的内容考虑去掉.应聘 DBA 的时候如果你的简历中写着大量的熟悉 HTML 、熟悉 Java 开发之类的话是没什么用的.
给招聘者足够多的技术信息.招聘者是迫不及待的要知道你的相关技术信息的。最好在简历中能说一些体现自己技术能力的地方,那怕是网络上的能够体现自己观点的技术讨论也好。如果有个个人技术积累的 Blog,那么无疑会让人眼前一亮,当然,你的 Blog 最好不要堆满了 Copy 来的文章.
节省资源,包括招聘者的时间.网络招聘者一般会留下 MSNIM 联系工具,尽量珍惜你同未来雇主的交流效率,千万别半个小时还在交流什么”我叫什么名字,以前在什么公司工作的事情”之类的废话,尽量先用 email 把要说的话说掉,然后问自己疑虑的东西足够了.

继续阅读

此文作者:, 位于 Review 分类 标签: , , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

图形工具是 DBA 的敌人?

最近 AnySQLITPub 上发了一个帖子: 多少DBA能离开OEM/TOAD/PLSQL Dev来工作? , 引来了很多人的讨论. 整理一下大家的观点,大致分为如下几类:

  • 工具能提高效率, 为啥不用?
  • 坚决不用;
  • 用不用都成; 解决问题就成;
  • 用来学习; 查看一些 SQL 很方便;

真是个仁者见仁,智者见智的问题. 图形化工具对于一个合格的 DBA 来说, 很多时候还是有缺点的,

一个图形化工具慢慢把 DBA 工作大众化了.这样作为一个DBA用图形化工具被人家看到了,显得不那么专业: 都是图形化的工具,普通开发人员随便点击几下子鼠标,不也成了 DBA 了? Oracle 10g 大大加强了 OEM 的功能, 很多人惊呼 Oracle 数据库管理员下岗的日子快到了. 在我看来,这恰恰是一个好消息。图形化工具上手容易,不可避免的很多人会浅尝辄止不去研究系统细节的问题,正是真正的 DBA 提高身价的好时候 :)

二是, 对图形化工具一旦产生依赖性, 应付突发事件的时候会有些局促感, 直观的东西隐藏了太多细节,而作为一个 DBA 更多的时候是要主动发现细节内容体现出来的问题; 这一点在讨论中很多人也提到了,一看没有安装 Toad ,就没法子上手了。

问题可能还有其他的,但是不是说 GUI 工具一无是处了,也不能说有这些问题就坚决不用 GUI 了。有的时候,开发人员依赖于 IDE 的, 就遇到的问题咨询 DBA ,不显得自己 IDE 用的很熟练的样子还真的说不过去; 再比如,抽取 DDL 语句这样的日常操作, GUI 工具的便利性还是有一些的。

还是针对图形化工具可能给我们带来的问题来说吧。”工具善其事,必先利其器”, 这个”器”可不是 GUI 工具哦. 建立一套针对自己的跨平台工具包是必须的,很多 DBA 都有一套适合自己的工具包. 当然,光有工具没有用,适当的提高一下记忆力也有必要,至少,再参加面试的时候可以唬主考官一下。

参见 AnySQL 的Blog上的PR


一句题外话:作为一个 DBA ,你是希望合格的 DBA 多一些还是少一些好呢?