AnySQL.net

    在网上看到过几次这样的问题, 当数据量极小时, 迁移只是很简单的一个事情时, 可以做做. 但当数据库达到100G或更大时, 迁移还是需要花费一定的时间的, 并且比较复杂的, 个人认为没有什么必要做这样的迁移, 首先我想不出来迁移后会对性能有很大的影响, 或者对于数据库管理上提供了很大的方便性? 同样的都是32位的平台, 迁移并不能解决大内存的利用问题. 因此得不到Capacity上的提升, 实在想不出有什么必要!

    对于一个重要应用的数据库, 作领导的应当尽量少作些这样的决定, 就算是新官上任要放几把火, 也不要发在这儿. 迁移过程中通常会带来性能和稳定性的问题, 我见过几个系统, 他们的DBA定期用EXP/IMP方式进行导出导入重新整理数据, 结果就是每次IMP回去后的前几天, 总是出现很多性能上的问题. 当你在不同的平台做这样的先移时, 遇到的问题可能更多, 你平时用的Job角本可以跑在Linux下了吗? 你的管理员熟悉Linux了吗?

    一般我只会考虑不同硬件平台之间的迁移, 例如从32位的Windows或Linux平台迁移到64平台的Unix平台中, 这样的迁移是为了以后长远的Capacity考虑, 为了在以后相应长的一段时间内可以支持业务的高速增长. 将这个时间用于解决其他的问题, 安全可以更有效地解决问题.

    在我们的环境中, 稳定和可用性是压到一切的, 因此这样的决定肯定是不会做的. 个人意见, 仅供参考!

    对于一些建在更新比较频繁的列上的索引, 或者是有大量记录被删除表上的索引, 需要定期进行Rebuild, 对于比较大表上的索引一般会考虑用一定的并行度去建, 以让索引在更短的时间内建好. 但不要忘了将索引的并行度重新设置为1(禁用并行), 否则很容易让所有的SQL都用并行方式来执行, 从而引起主机崩溃. 在很忙的OLTP系统中, 可能常会遇到Resource Busy的错误, 如何确保修改能最后成功呢? 就需要一段角本来处理一下这个错误, 下面是我常用的一段角本:

alter index ...... rebuild ... parallel ... ONLINE;

declare
  resource_busy exception;
  pragma exception_init (resource_busy,-54);
begin
loop
   begin
     execute immediate 'alter index ...... noparallel';
     exit;
   exception
    when resource_busy then
     dbms_lock.sleep(1);
   end;
end loop;
end;
/

    这个角本也可以用在其他的地方, 或者改一下错误号(-54)来处理其他的错误, 怎么用就看你的了!

    这个最有价值的一击出自Alaska州政府税收部门, 工程师在做维护工作时, 意外地删除了一个石油公司的帐户, 并且恰好将备份的磁带也格式化了一下. 等发现问题时, 却发现所作的备份根本就不可用. 从300箱纸质档案上重新输入数据.

• 技术员意外删除数据及格式化含有备份的磁带
• 被删除数据和石油业的税收有关
• 70个人花了6个星期来重新录入数据
• 失误的代价超过220000美金

    如果中国公司出现这样的事故, 估计就没有这么值钱了, 因为找重新录入的人员很便宜, 而且可以强制加班. 另外也未必有这么重要的数据.

    从DBA的角度, 怎么样就算高级DBA了呢? 我想不需要懂得很多, 如RAC/复制/Streams等知识, 要求对常用的知识了解得比较深刻, 可以将这些常用的知识在特定的场合下自由地运用出来, 做事细心认真, 具有良好的习惯, 能够想到任务可能造成的额外影响, 并提前作好对策, 不能时不时地捅些乱子出来, 有一天和chao_ping聊天时, 我发表了上面的看法.

    希望看到这篇后, DBA至少要学会备份和恢复, Tom Kyte也如是说, 我们的领导也致少得注意备份和恢复. 我想数据的增值速度会比股市的增值速度快, 好好保护你的数据.

    第一次Fenng引荐我时, 没有打电话, 因此没成为第一批. 后来Jack Han在MSN上主动找我, 真是不好意思. 发现我和Biti大师的情况差不多. 用的126的邮箱, 用Web方式登录才发现确认信居然跑到垃圾邮件列表中了, 因此在本地用Foxmail收时怎么也没有收下来, 什么规则也没有设, 就这样了! 其实信昨天就到达了, 没有在外漂泊一个月.

    Biti被特意推荐到第100位, 不知道我是多少位? 第99位或第101位也是很好的位置, 我喜欢.

    当Oracle ACE的好处:

1, 在OTN上有显著ACE标志(显示个人简介, 有ACE图标)
2, 礼物, 应当是一个水晶和一件很温暖的衣服
3, 受邀参加Oracle ACE的聚会

    要成为ACE, 请考虑以下几方面:

1, OTN论坛上勇跃发言
2, 发表技术文章, 代码或工具
3, 编写Oracle图书
4, 维护一个Oracle相关的Blog
5, 在Oracle公共活动中演讲
6, 参加Oracle活动(客户活动, Beta测试, 用户组等)

    在这儿不能全列出, 不仅仅局限于这些.

    今日早上, 在网上看到一篇贴子, 问了如下两个问题:

数据仓库中有2007年之前的数据

问题一:
如何保持erp与数据仓库中2007年数据一致而数据仓库中2007年之前数据不变(以前通过dbms_mview.refresh('xxx','fast'))?

问题二:
我对x物化视图做了一个全部刷新,但是x物化视图中的数据全部变成2007年的数据,以前数据丢失?如阿恢复到刷新前的状态

    其中第一个问题是个难题, 现在很多公司都在想这样的一个解决方案, 其实就是一个实时复制方案, 从在的角度来说, 这方面可以用的方案有: 1, Quest公司的SharePlex; 2, DSG公司的RealSync(没有一点印象); 3, Oracle公司的Stream. 前两者都是比较贵的解决方案, Oracle的Stream懂的人少, 而且在9i中还不够稳定. 物化视图并不适合用来归档生产库的数据到历史库, 原来就象第二点所说的那样, 如果进行全部刷新, Oracle会先在目标数据库上运行一个DELETE命令来删除所有的数据(你可以SQL_TRACE一把), 估计这位老兄也是查了资料或翻了贴子后, 觉得物化视图可以做到这一点, 所以这样做了一把, 结果就是数据被删除了.

    最近我也一直在想这样的一个解决的方法, 在物化视图中, 用物化视图日志来捕获对表的变更, 是一个比较好的方法(对于负荷不是很高的数据库), 完全可以利用这一点, 自已编程来实现和物化视图刷新这样的功能, 最近我写的refresh_mysql角本就是用来做这个的. 当然当初考虑的是从Oracle中将数据比较实时地同步到MySQL或其他数据库中, 从角本的名字也可以猜出来. 但后来发现数据源也未必一定要是Oracle了, 其他的库可以用触发器来实现Oracle中的物化视图日志的功能, 目标数据也可以是Oracle.

    如何高效地维护一个表的逻辑拷贝, 其实是一个比较难的问题, 象SharePlex是Quest公司的最主要的拳头产品.