Oracle Life

Oracle大学的性能优化培训课程

eygle@eygle.com(eygle) — Tue, 16 Mar 2010 11:47:06 +0800

在首页上，这几天会帮助Oracle 大学做一个条幅广告，宣传的是OU最近将举行的一个培训活动。
活动链接如下：
http://www.oracle.com/global/cn/education/promotions/guruweek_fy10q4.htm

这次培训OU请到了Arup Nanda，我在美国参加OpenWorld时曾经和Arup有过数面之缘，这一次有机会一起主讲这样一个课程实在是一种缘分。

这个课程设计为4天，Arup 2天，我讲1天，OU的包光磊老师讲1天。

具体内容可以参看以上链接。

如果有感兴趣的报名者，据说报 eygle.com 的来源，可以获得最低折扣。当然OU的培训收费是不便宜的，有兴趣的关注一下吧！

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/oracle_arup_eygle_bao.html

感谢武汉博文视点赞助ACOUG首次活动

eygle@eygle.com(eygle) — Sun, 14 Mar 2010 12:22:26 +0800

作者：eygle 发布在 eygle.com

周日，收到武汉博文视点发来的一箱图书，这是周筠老师得知我们将举行ACOUG的首次地面活动，欣然提供的图书赞助。

赞助的图书包含三种，一本是我们的新书《Oracle DBA手记》、一本是陈吉平的《构建Oracle高可用环境》、第三本是李笑来的《把时间当作朋友》。
Piner的书出版1年多来重印多次,是一本不可多得的好书，也是Oracle DBA们必备的案头书；而笑来的《把时间当作朋友》则是帮助我们开启心智，了解自我的一本好书。
我们的《Oracle DBA手记》则还需要时间的考验。

感谢博文视点，感谢周筠老师对我们活动的支持！

这些书会分几次在我们的活动中送出，我们也欢迎其他赞助！

-The End-

相关文章|Related Articles

评论数量(3)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/acoug_broadview.html

讨论: 无备份的数据库如何应对故障?

eygle@eygle.com(eygle) — Wed, 10 Mar 2010 10:45:12 +0800

作者：eygle 发布在 eygle.com

近期，在为一个客户的数据库制定紧急预案，这个数据库数据量大约在1.4T左右。由于客户没有额外的存储资源用于备份，所以数据库目前存在了很大的安全风险。
虽然存储级别有一定的安全防范，但是如果遇到数据损失、坏块、文件损坏等问题，将无法应对。

SQL> select sum(bytes)/1024/1024/1024/1024 TB from v$datafile;

TB
----------
1.39508572

当然我们有一些折中的手段可以采用，比如备份数据结构，系统表空间等，在故障时快速回复核心业务。同时，如果是常规的错误，可以通过一系列的内部手段进行强制恢复，当然是以损失一部分数据为代价的。

探讨一下，哪些数据库是无备份的?无备份大家是如何应对故障的？

相关文章|Related Articles

评论数量(15)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/h2recovery_nobackup.html

飞信招聘数据库开发工程师 (开发DBA)

eygle@eygle.com(eygle) — Tue, 09 Mar 2010 10:36:35 +0800

作者：eygle 发布在 eygle.com

帮朋友发一则招聘信息：

　　工作地点 : 北京　　
　　职位描述：
　　
　　1 ．负责 DB 开发、 DB 性能优化，以及开发 / 测试库的日常维护；
　　2 ．负责 DB Schema 设计、表结构设计，审核开发人员SQL性能,及相关文档编写；
　　3 ．完善和宣传 DB 开发规范和相关流程，提高应用开发人员 DB 开发技能。
　　
　　任职要求：
　　
　　熟悉 SQL Sever 等数据库体系结构、性能优化，深入掌握 SQL 和 T-SQL ；
　　熟悉关系数据库原理和设计，具有大型项目数据库设计和开发经验者优先；
　　具有一定的数据建模能力，掌握数据库开发与设计工具的使用；
　　具有较强的总结能力和培训能力，良好的沟通技能、团队合作能力；
　　熟悉 .NET 开发则优佳（不参与.net开发) 。
　　
　　参与飞信官网的数据库开发设计工作，
　　关于飞信，请访问：
　　http://www.fetion.com.cn/
　　
　　请加MSN: 　　
　　334488@live.cn
　　或者发邮件联系，谢谢！

-The End-

相关文章|Related Articles

评论数量(6)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/fetion_dba.html

ACOUG 首次活动接受报名

eygle@eygle.com(eygle) — Mon, 08 Mar 2010 17:30:08 +0800

作者：eygle 发布在 eygle.com

大家好，ACOUG的首次地面活动现在接受报名。

请发送报名邮件到 enroll@acoug.org 信箱，报名请按以下格式填写。
报名请在邮件附件用文本文件(txt格式)以逗号分割符填写，请尽量填写详细，我们将按报名顺序安排活动参与。
当然你还可以在邮件正文告诉我们你的想法，感兴趣的议题以及你想说的。

下面是报名的信息格式及示范文本：
姓名,性别,公司名称,职务,工作年限,手机,工作电话,邮件,MSN,QQ,关注点
盖国强,男,北京恩墨科技有限公司,DBA,10,13911812803,13911812803,eygle@eygle.com,eygle@hotmail.com,1483367,Oracle 数据库技术

"关注点"的备选项建议如下：Oracle数据库技术，Oracle中间件技术，Oracle企业套件技术，操作系统技术，网络技术，存储技术。
如果关注点不在以上备选项中，请以这种格式注明：其它（XXXXXX）。

感谢大家的支持，预祝ACOUG的第一次活动能够成功举行。

-The End-

相关文章|Related Articles

ACOUG - All China Oracle User Group Start

评论数量(15)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/acoug_enroll.html

ACOUG - All China Oracle User Group Start

eygle@eygle.com(eygle) — Sun, 07 Mar 2010 00:22:47 +0800

作者：eygle 发布在 eygle.com

很长一段时间以来，我一直有一个单纯的梦想，就是为喜欢Oracle的技术爱好者们做一点点公益的事情。
在过去的6年间，我在北京做过不少公开的活动，将我有限的经验与知识分享出去，这些活动每次都有很多新的面孔出现，有些成为我的朋友，有些真的就踏上了DBA之路，这些积极的促进是我一直乐于去做这样活动的主要原因。

可是做一点"公益"的事情并不容易，直到最近，当我觉得可以解决这其中的所有问题之后，这一切成为可能。

ACOUG 正是基于这样一件事情我们发起的一个站点，ACOUG的含义是All China Oracle User Group，这个名字太过大了，存粹是为了定义这样一个域名而得来的，所以请不要计较我们最终能够涉及到多少产品与内容，我们只是想尽力去做一件想了很久而一直没有做的事情。

所以要做一个用户组，是因为在几次去美国期间，在OOW上见到各个国家或地区的Oracle用户组组织了非常多的活动，而国内最活跃的是论坛，ITPUB.NET是首屈一指的，但是国内没有类似国外的用户组的组织。CNOUG也是一个非常不错的地方，但是CNOUG实际上是另外一个ITPUB，以论坛为主的社区，而社区也正是一个中国的特色。

ACOUG，其实开始我想也许成为BJOUG可能会更为确切，因为我们的初始活动可能只能在北京开始尝试。只是后来借鉴了一个印度的新闻组域名，得来了ACOUG的名字。

ACOUG，首先我们并不会做论坛，ITPUB在Oracle技术方面，在国内已经无可超越，技术问题的探讨那里仍然是最为合适的地方，我们想做的是一些地面活动，一直以来，我想搭建一个平台，那些热爱技术的、有一技之长的朋友，可以到这个平台上来演讲、分享、交流，我们通过这个平台提供一个分享和展现的机会，如果你乐于分享，并且享受过程，那这里就是你的舞台；而对于那些刚刚开始学习Oracle技术，又想接触和深入了解一下这个圈子的朋友，在这个平台下，我们为你准备好了位置，你可以来聆听和探讨。

ACOUG，这个站点的存在意义，最终我们设计将这个站点做成一个"技术博客"，我们希望邀请那些国内数据库领域的爱好者们加入，会有一些简单的规则，大家可以定期提供一些自己深入研究的技术文章，将这个站点作为一个统一的展现平台聚合起来，这个作用和国外的很多站点类似。这样的一个想法，没有什么新奇之处，我们只是希望，能够在朋友们的支持下，做一点新的事情、做一点有益的事情，基于爱好，基于那一直存在的理想主义。

这个想法，在年初和Kamus提起时，两个人达成了惊人的一致，就连想到的ACOUG的名字都是同样的，然后Kamus尝试用不同的程序搭建了网站的后台，最后或者说暂时我们选择了WP。Kamus在这件事情上投入了很多精力，感谢他！

搭建这个平台，我想，其实北京有众多的技术高手，如果每个人都能够分享一个主题，那么每两个月搞一次活动，我想应该是不难的，而以前一直存在的场地、费用问题，现在有我的恩墨科技做一点支持，靠朋友们的一点赞助，以及来自Oracle官方的一些支持，这些问题不再存在。

有时候我们不去做一件事情的借口是忙，事实上不是，我想即便我自己每个月抽出一两天，花费1~2小时去分享一个技术主题是非常容易的，唯一的借口是我们的懒惰。另外一个问题是，很多人不愿意为没有收益的事情付出，而我的观点是，有付出一定是有回报的，虽然这个回报可能在很久之后。而我愿意做这件事，更主要的是如前所述，在赤裸裸的为了追逐金钱而努力之外，我们还一直保有一点理想主义，我相信大家都有。如果缺少一个组织者，那我们愿意来试试看。

在我们这个消息传出去之后，我在美国认识的一位ACE Director - Ameed Taylor 已经发来邮件说愿意到现场来支持我们的活动，我说给点时间我们尝试一下，如果ACOUG能够发展下去，我希望有机会请更多的人来北京，或者在外地开展活动。

最后，我想，也许会有人质疑我们关于"公益"的动机，那么是的，我心里面窃窃的以为，如果我们搞的成功，那么也许我们这个舞台可以让一些具有真正技术的人凸显出来，所以乐于分享的人，也许会有些意想不到的收获，当然这些活动的组织者，也许有机会在更广泛的领域为业者所知，我说的有付出就一定有回报，某种程度上与此有关。而如果组织有价值，活动有价值，其他的交给时间吧。

在我的设想里，以后，我不是主要的演讲者了，越来越多的年轻人、技术专家涌现出来，如果你们愿意，这里有你的位置，当然我们目前还无法给出报酬。

第一次活动我们定在了3月20日，时间有点紧张，我的意思是，给我们一点压力，让这件事情尽快动起来，有开始才有未来，我跟Kamus说，行动有时候比思想更重要。

好了，这个活动，对于参与者，也许唯一的要求是一个详尽的注册流程，我们希望，我们的每一次活动所抵达的地方和人群都能够被记录下来，这是对我们这些尝试的鼓励和纪念。

关于ACOUG的网站，由于我们都不是专业的人士，如果有朋友碰巧懂得PHP或WP运用得好，我们诚挚的邀请志愿者加入这个站点的维护工作，谢谢。

就写这么多，让我们动起来吧！

-The End-

相关文章|Related Articles

评论数量(19)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/acoug_starting.html

kcbgtcr 错误小记

eygle@eygle.com(eygle) — Thu, 04 Mar 2010 13:37:49 +0800

作者：eygle 发布在 eygle.com

在很久以前遇到过一次kcbgtcr_13号错误，那次错误在数据库恢复时出现，最后导致数据库不能够完成恢复。

最近又遇到类似错误，错误出现在INSERT操作时，错误出现，进程crash，任务失败，重新执行可以通过。
kcbgtcr 是Oracle数据库最重要的函数之一，其含义为：Kernal Cache Buffer GeT Cosistents Read,也就是数据库的一致性读操作，后面的代码有很多种，代表在不同的层面上出现问题。
Metalink 的 Note 415773.1 - Diagnostics and Solutions for kcbgtcr() Related Internal Errors记录了与此相关的很多问题。

不讨论具体的问题，根据代码的含义实际上可以知道，出现这类错误，基本上都是由于CR读异常导致的，CR读涉及的各个层面出现问题，如DataBlock,Undo Header,Undo Block出问题，都可能导致异常。

kcbgtcr_13号错误是指在构造一个CR读时，检查Buffer时发现其SCN不可用，判断出错导致代码异常，进程Crash掉，这类错误可能是Buffer过小，重用过快导致的，也可能是数据变更过于频繁导致。

这类错误极其少见，一旦出现要非常慎重的处理，有些Bug与此有关，需要通过Metalink确认，数据库在部署时最好应用最新的PSU。
下面是这次故障的错误堆栈摘要：

*** 2010-03-03 14:15:04.436
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcbgtcr_13], [], [], [], [], [], [], []
Current SQL statement for this session:
INSERT INTO CT_INFO (RPT_DATE, RGN_CODE, .......
----- PL/SQL Call Stack -----
object      line object
handle    number name
700000206d666a0       338 procedure CT_INFO_S
7000001a89a3f30         3 anonymous block
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst+001c          bl       ksedst1              FFFFFFFFFFED73C ? 000000006 ?
ksedmp+0290          bl       ksedst               104A48040 ?
ksfdmp+0018          bl       03F326DC
kgerinv+00dc         bl       _ptrgl
kgeasnmierr+004c     bl       kgerinv              000000000 ? 10566823C ?
                                                   100000013 ? 225D0C00130000 ?
                                                   000000000 ?
kcbassertbd+0074     bl       kgeasnmierr          1101955E0 ? 110450040 ?
                                                   105668AC4 ? 000000000 ?
                                                   000000000 ? 700000206F807C0 ?
                                                   000000000 ? 000000051 ?
kcbgtcr+2a68         bl       kcbassertbd          105668AC0 ? FFFFFFFFFFEC608 ?
ktspgfbs+0144        bl       kcbgtcr              102147B38 ? 000000000 ?
                                                   70000002EB3F448 ? 000000001 ?
ktspfsrch+00b8       bl       ktspgfbs             FFFFFFFFFFEE028 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   1101FFEF8 ? FFFFFFFFFFEDA78 ?
                                                   000000000 ?
ktspscan_bmb+021c    bl       ktspfsrch            700000010018078 ?
                                                   FFFFFFFFFFEE028 ?
ktspgsp_cbk1+07c4    bl       ktspscan_bmb         1FE800000001 ?
ktspgsp_cbk+00a8     bl       ktspgsp_cbk1         1130D0A00 ? 000000000 ?
                                                   1028F3668 ? FFFFFFFFFFEDF40 ?
                                                   11022A548 ? 110266D40 ?
                                                   000000000 ? 000000014 ?
kdtgsp+0504          bl       ktspgsp_cbk          000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
                                                   000000000 ? 000000000 ?
kdtgsph+02f8         bl       kdtgsp               10500E820 ? 110195760 ?
kdtFlushBuf+0288     bl       kdtgsph              1105F8E40 ? 000000000 ?
insflush+0348        bl       kdtFlushBuf          1105F8E40 ?
insrow+0384          bl       insflush             1105F8E40 ? 000000000 ?
                                                   1101BECF0 ? FFFFFFFFFFF13E0 ?
                                                   2C000100000004 ?
insdrv+0428          bl       insrow               1105F8E40 ? FFFFFFFFFFF13E0 ?
                                                   000000000 ?
inscovexe+02b8       bl       insdrv               1105F8E40 ?
insExecStmtExecIniE bl       01FA0954
ngine+005c
insexe+02f8          bl       insExecStmtExecIniE FFFFFFFFFFF2318 ?
                              ngine                FFFFFFFFFFF2310 ? 110527020 ?
opiexe+2738          bl       insexe               1105942B8 ? FFFFFFFFFFF2978 ?
opipls+185c          bl       opiexe               FFFFFFFFFFF3CC0 ?
                                                   FFFFFFFFFFF3DA8 ?
                                                   FFFFFFFFFFF3C60 ?
opiodr+0ae0          bl       _ptrgl
rpidrus+01bc         bl       opiodr               66FFFF5A80 ? 6025E14E0 ?
                                                   FFFFFFFFFFF6B80 ? CE9A84B20 ?
skgmstack+00c8       bl       _ptrgl
rpidru+0088          bl       skgmstack            10233AE20 ? 000000000 ?
                                                   000000002 ? 000000000 ?
                                                   FFFFFFFFFFF6348 ?
rpiswu2+034c         bl       _ptrgl
rpidrv+095c          bl       rpiswu2              70000020458E188 ? 11052E3A0 ?
                                                   11046AA58 ? 000000000 ?
                                                   FFFFFFFFFFF6120 ?
                                                   3C00000000 ? 000000000 ?
                                                   000000000 ?
psddr0+02bc          bl       03F32174
psdnal+01d0          bl       psddr0               CFFFF6DB8 ? 6600000000 ?
                                                   FFFFFFFFFFF6B80 ?
                                                   30100BA3A8 ?
pevm_EXECC+01f8      bl       _ptrgl
pfrinstr_EXECC+0070 bl       pevm_EXECC           70000019DB5AC60 ? 000000000 ?
                                                   7000001C12D897A ?
pfrrun_no_tool+005c bl       _ptrgl
pfrrun+1014          bl       pfrrun_no_tool       FFFFFFFFFFF6EE0 ?
                                                   7000001A89A3F30 ? 3100EAA30 ?
plsql_run+06b4       bl       pfrrun               11048A228 ?
peicnt+0224          bl       plsql_run            11048A228 ? 1000000000418 ?
                                                   000000000 ?
kkxexe+0250          bl       peicnt               FFFFFFFFFFF81F8 ? 11048A228 ?
opiexe+2ef8          bl       kkxexe               110483218 ?
kpoal8+0edc          bl       opiexe               FFFFFFFFFFFB814 ?
                                                   FFFFFFFFFFFB588 ?
                                                   FFFFFFFFFFF99E8 ?
opiodr+0ae0          bl       _ptrgl
ttcpip+1020          bl       _ptrgl
opitsk+1124          bl       01FA3344
opiino+0990          bl       opitsk               000000000 ? 000000000 ?
opiodr+0ae0          bl       _ptrgl
opidrv+0484          bl       01FA2198
sou2o+0090           bl       opidrv               3C02DB56BC ? 44065F000 ?
                                                   FFFFFFFFFFFF750 ?
opimai_real+01bc     bl       01F9FAB4
main+0098            bl       opimai_real          000000000 ? 000000000 ?
__start+0098         bl       main                 000000000 ? 000000000 ?

--------------------- Binary Stack Dump ---------------------

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/kcbgtcr.html

ORA-00600 3020 错误案例一则

eygle@eygle.com(eygle) — Tue, 02 Mar 2010 08:29:28 +0800

作者：eygle 发布在 eygle.com

最近遇到一则ORA-600的3020错误，数据库在故障恢复中，应用归档日志时遇到3020错误：

ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement:
alter database recover logfile '/arch/prod1_2711_681480148.arc'
ORA-00283: recovery session canceled due to errors
ORA-12801: error signaled in parallel query server P011, instance hpdb1:PROD1 (1)
ORA-00600: internal error code, arguments: [3020], [37], [94633], [2], [3659], [604], [16], []
ORA-10567: Redo is inconsistent with data block (file# 37, block# 94633)
ORA-10564: tablespace APPS_UNDOTS2
ORA-01110: data file 37

出现这个错误后，恢复中断，无法继续，3020错误在Metalink上的解释，主要原因是：

This is called a 'STUCK RECOVERY'.
There is an inconsistency between the information stored in the redo
and the information stored in a database block being recovered.

也就是说，在恢复时发现Redo里面记录的信息和被恢复的数据块信息不一致，导致恢复无法继续。比如Update Some record from 3 to 2,结果发现该记录根本不是3，恢复无法继续。

这个错误可能是由于写Redo的某个操作丢失，这可能是由于异常宕机或存储故障导致的。
This error can be reported if any of these updates are lost for some reason.

出现这个错误，如果没有备份，数据也不是特别重要，则可以通过一些隐含参数或强制手段来打开数据库，不过不可避免的会出现数据损失，Olive做过一次这样的尝试。

这次处理这个案例，最后选择了不完全恢复，补录数据，有时候放弃也是一种恢复！

-The End-

相关文章|Related Articles

评论数量(0)|Add Comments

本文网址：http://www.eygle.com/archives/2010/03/ora_00600_3020.html

SMON: recover undo segment 与事务恢复

eygle@eygle.com(eygle) — Tue, 23 Feb 2010 07:54:09 +0800

作者：eygle 发布在 eygle.com

在一些系统异常之后，尤其是异常Down机之后，数据库里可能会看到类似如下的提示信息：

SMON: about to recover undo segment 23
SMON: mark undo segment 23 as available

这些信息意味着，数据库需要这些回滚段的信息去恢复一些未完成事务，多数情况下，这些事务都能够得到恢复，但是如果不幸，在异常宕机时丢失了部分Write操作，则可能无法完成恢复，出现灾难。

以下一段日志来自生产数据库的日志恢复：

SMON: about to recover undo segment 23
SMON: mark undo segment 23 as available
SMON: about to recover undo segment 24
SMON: mark undo segment 24 as available
SMON: about to recover undo segment 25
Dead transaction 0x0019.01b.00009fc7 recovered by SMON
SMON: mark undo segment 25 as available
SMON: about to recover undo segment 26
SMON: mark undo segment 26 as available
SMON: about to recover undo segment 27
SMON: mark undo segment 27 as available

在这些日志中可以看到，Oracle在恢复一个死事务，0x0019.01b.00009fc7，这个事务使用的回滚段是0x19号，也就是25号回滚段，可以看到在随后的日志中，Oracle启用25号回滚段。

这就是由事务恢复引发的回滚段操作，以下日志可以作为类似的参考：

Dead transaction 0x0044.010.00007746 recovered by SMON
SMON: mark undo segment 68 as available
SMON: about to recover undo segment 69
SMON: mark undo segment 69 as available
SMON: about to recover undo segment 70
SMON: mark undo segment 70 as available
SMON: about to recover undo segment 71
SMON: mark undo segment 71 as available
SMON: about to recover undo segment 72
SMON: mark undo segment 72 as available
SMON: about to recover undo segment 75
SMON: mark undo segment 75 as available
SMON: about to recover undo segment 76
SMON: mark undo segment 76 as available
SMON: about to recover undo segment 77
SMON: mark undo segment 77 as available
SMON: about to recover undo segment 78
SMON: mark undo segment 78 as available
SMON: about to recover undo segment 79
Dead transaction 0x004f.00e.00005d5e recovered by SMON
SMON: mark undo segment 79 as available
SMON: about to recover undo segment 81
SMON: about to recover undo segment 120
SMON: mark undo segment 120 as available
SMON: about to recover undo segment 122
Dead transaction 0x009a.006.00003056 recovered by SMON
SMON: mark undo segment 154 as available
SMON: about to recover undo segment 156
SMON: mark undo segment 156 as available

某些恢复可能需要很长的时间，在此期间的一些异常可能导致SMON Crash，进而数据库Instance崩溃。
Oracle的一些内部事件允许设置debug_mode，以便允许在AUM模式下，手工进行回滚段的处理：

alert session set "_smu_debug_mode"=4;
alert rollback segment "_SYSSMU10$" ONLINE;

了解这些手段，但是需要谨慎使用，特别是当你决定DROP某个回滚段时。

设置10513事件，可以阻止SMON在启动数据库后执行恢复，这可以给我们一些诊断时间，在参数文件中如下设置：
event = 10513 trace name context forever,level 2

总之，和UNDO相关的操作极度危险，在一些金融领域，任何一个丢失的事务都可能成为灾难，所以了解任何一个动作及其可能带来的影响是对我们的重大考验。

判断永远比操作更重要！

-The End-

相关文章|Related Articles

评论数量(1)|Add Comments

本文网址：http://www.eygle.com/archives/2010/02/smon_recover_undo_segment.html

祝大家虎年大吉新年快乐

eygle@eygle.com(eygle) — Sat, 13 Feb 2010 16:49:57 +0800

作者：eygle 发布在 eygle.com

今天回到了东北，冰天雪地的家乡，温暖的火炕。

祝大家伙新年快乐，万事如意，虎年里面虎虎生威。

相关文章|Related Articles

评论数量(4)|Add Comments

本文网址：http://www.eygle.com/archives/2010/02/happy_tiger_year.html

Oracle Life

Oracle大学的性能优化培训课程

感谢武汉博文视点赞助ACOUG首次活动

讨论: 无备份的数据库如何应对故障?

飞信招聘数据库开发工程师 (开发DBA)

ACOUG 首次活动接受报名

ACOUG - All China Oracle User Group Start

kcbgtcr 错误小记

ORA-00600 3020 错误案例一则

SMON: recover undo segment 与 事务恢复

祝大家虎年大吉 新年快乐

SMON: recover undo segment 与事务恢复

祝大家虎年大吉新年快乐