AnySQL.net

    由于历史的原因, 居然有机会清理4TeraBytes大小的表, 而且这个表是在字典管理表空间(DMT)上的, 新建的都不会再用字典管理表空间了, 估计在其他地方是不可能遇到的了. 用最吐的CTAS方法将数据归档了一部份, 并重新设计分区的逻辑, 完成后就得将这个表删除以释放空间.

    心中很是担心害怕, 不过也没有办法, 只能继续. 大致经过了如下步骤:

drop index ...;
truncate table ... reuse storage;
alter table ... deallocate unused keep 2000000m;
alter table ... deallocate unused keep 1500000m;
alter table ... deallocate unused keep 1000000m;
alter table ... deallocate unused keep 500000m;
alter table ... deallocate unused keep 0;
drop table ...;

    发现KEEP的最大值只能是2000000m, 再加1M都不行了. 整个过程进行了大约1.5个小时, 每条命令后还加入了表空间COALESCE, 全程盯着数据库的Load, 累!

    还好安全地完成任务! 为了防止出现ST Enqueue, 可以对那个时间段修改比较忙的表事先分配几个Extent.

    前段时间, 一个澳大利亚的网友说他的Oracle库中某个表空间只留下了几个数据文件, 还能不能恢复. 在这儿不讨论如何恢复数据的问题, 要关注引起这个问题的根源.

    根本原因是他们请了一个SQL Server DBA, 兼职(顺便)管管Oracle数据库, 当某些数据过时了, 要归档起来, 这个SQL DBA就将表空间从Oracle中删除了. 原因是SQL Server中是可以这样做的, 只要数据文件存在, 就可以挂到新SQL Server数据库中, 不幸运地是, 他这个猜测错了. 后来他们的客户再来要求查询过去的数据时, 就发生了这个问题.

    有两个方面的问题, 值得思考. 从DBA个人角度来说, 不应当这么随便地只根据自已的猜测, 就去做删除数据这样的操作, 这个思界, Google一下, 有这么难吗? 如果DBA有这种想法或倾向, 那么你很难被大公司录用. 从公司角度来说, 让不懂的人去做重要的事, 还是兼职的, 出了问题, 公司应当承担主要的责任.

    至于大家都关心的结局问题, 他们联系Oracle了, 但等了很久(一周)Oracle也没有派人去作DUL恢复, 在找了一个更旧的DMP恢复进去后, 他们的客户也就不追究了. 我也给了他们一个报价, 最后没有被他们的领导采用. 当然那个兼职的SQL DBA, 肯定是要解除劳务关系了.

    过年要去烧香拜佛了, 让更多的SQL DBA兼管Oracle库吧!

    服务越来越重要, 来看一个国外Oracle专家提供技术服务的报价, 都是以美元为单位的. 服务提供者为高级的具有OCP证书的DBA专业人员, 按服务地点可分为远程和现场, 按服务时间可分为临时服务和不小于多少小时的包时服务.

    1, 远程服务价格,　临时: 每小时175 USD. 保证80小时: 每小时165USD, 至少13200美刀.

    2, 现场服务, 临时: 每小时275 USD. 保证80小时: 每小时265USD, 至少21200美刀.

    对于Oracle RAC的服务, 收费要贵一些了, 看来得好好学学RAC了.

    1, 远程服务价格,　临时: 每小时200 USD. 保证80小时: 每小时190USD, 至少15200美刀.

    2, 现场服务, 临时: 每小时350 USD. 保证80小时: 每小时340USD, 至少27200美刀.

    3, 每月远程固定服务, 主节点每个月1400 USD, 每个从节点500 USD, 一个月至少1900美刀.

    对于上门服务, 路上时间也计费的, 并且要支付相关费用(路费, 住宿费, 饭费?). 要是本人提供的恢复服务能按0.1分钱一条记录算的话, 早就可以退休了.

    有人在Itpub上问Oracle 817建分区表怎么出错了? 错误如下:

ORA-00604: error occurred at recursive SQL level 1
ORA-00904: invalid column name

    通过设置SQL跟踪, 发现了引起错误的SQL语句.

PARSE ERROR #5:len=127 dep=1 uid=0 oct=2 lid=0 tim=0 err=904
insert into partcol$ (obj#, intcol#, col#, pos#, spare1, segcol#,
    type#, charsetform) values (:1, :2, :3, :4, :5, :6, :7, :8)

    看一下现在的partcol$表的表结构.

SQL> desc sys.partcol$
Name    Type   Nullable Default Comments
------- ------ -------- ------- --------
OBJ#    NUMBER
INTCOL# NUMBER
COL#    NUMBER
POS#    NUMBER
SPARE1  NUMBER Y

    原来是这个系统表少了几个列, 什么原因造成的呢? 我首先想到的就是升级时只升了软件, 没有运行Oracle的升级角本. 我们可以在rdbms/admin目录下grep下这个表. 主要有三个角本包含了对这个表的结构修改.

c0801060.sql:alter table partcol$ add (segcol# number, ...
migrate.bsq:create table partcol$ (
sql.bsq:create table partcol$ (

    通过进一步对比, 发现这实例中的表结构和migrate.bsq中的一致, 因此初步确定这是一个从Oracle 7升级上来的数据库. 看谁在调用c0801060这个SQL文件.

u0801060.sql:Rem        STAGE 3: call c0801060.sql:
u0801060.sql:@@c0801060

    可以看到Oracle在从816升到817时需要加这三个列, 而出现这个错误的原因也是因为只是将Oracle执行文件升级到817了,而没有在Oracle数据库里跑升级角本u0801070. 是谁在提供这样的技术支持? 新瓶装旧酒!

    最近流行自我恢过, 有人在ITPub上有人问DBA生涯中最难人忘怀的误操作. 最常见的有如下几类:

    rm误删除文件, 解决办法可以参考Fenng的贴子, 这其中良好的习惯和权限管理显得很重要, 必要时写些角本来进行删除操作, 不容易范错.

    连错数据库, 这种事发生的事也比较多. 如要连Standby的连到Primary了, 结果将生产库关闭了(这事这儿也发生过). 要连本机的连到生产库了, 要连测试库的连到生产库了, 连错库后用初始化角本去初始化造成了大问题.

    拷贝粘贴问题, 很习惯将命令粘贴到窗口中去跑, 结果拷的不是想要跑的命令, 而是拷了错误的DROP或TRUNCATE命令, 这个错误我也范过, 还好只是得到一堆ORA-00942(表或视图找不到)错误, 后来就不这么做了, 都是拷到一个SQL文件中, 然后cat检查一下再跑.

    不够小心, 如要DROP以TEMP结尾的表, 结果忘了打最后的TEMP, 将正式表删除了.

    DBA范了错有时很严重, 见过两次DBA因为这种下岗的. 怎么没有人提这个? OEM或Toad中误按删除(Delete)键, 将表或用户或表空间删除了, 帮人家恢复了几次这类错误, 因此记忆很深刻. 这个可以从加强权限入手, 不要让这类工具以DBA权限去登录, 以前我都是只用具有SELECT CATALOG ROLE和SELECT ANY TABLE权限的用户登录的.

    另外还有做了DBA, 但不作为的, 结果是遇到问题时无法恢复. 或者在服务器上试装软件的, 结果安装程序将当前联机日志删除了.