作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    差不多四个月前发了一篇Oracle DUL不行就用AUL, 是为广东某地公安局所作的一次数据恢复的经历, 他们某系统中用CLOB来存放了很多的法律, 法规以及批文信息, 因为存贮上的某种原因, 导致了系统表空间出现了很多的坏块, 因而需要用AUL这样的软件来恢复数据.

    一开始找的并不是我, 人家要的是Oracle原厂的服务, 因为原厂的DUL工具, 没有考虑变长字符集中CLOB数据的问题, 因此没有办法处理大量CLOB中的中文信息, 在Oracle恢复了不包含CLOB列的表后, 某技术服务公司的工程师向他们推荐了我. 去年也为其他地方公安局提供过类似服务, 都是很顺利地恢复出数据, 然后支付相应的旨用.

    此次也是一样, 一科长级别的人与我电话构通的, 说就这么点服务费没有问题, 不用担心. 其实就这点费用, 的确不算什么, 组织几个人在国内参观/开会一次的费用也大大超过这个数了, 所以也没有什么担心, 再说牵线的那公司还是很有名的, 国内一流的Oracle技术服务提供商. 一向认为事情会以简单的方式去处理掉, 就不想什么其他先提供服务再说了, 毕竟人家的数据已经好几天没能访问了, 也就不先预收点劳务费了.

    但后来的事情发展还是出于意料的, 本月初我打那课长的电话还是接的, 这几天则无论如何打都不接了, 这分明是想赖帐了. 因为请的原厂的恢复费用他们也没有给, 更别说我的了. 不过一个公安科长级别的人物, 没有什么理由不接这样的电话的, 服务公司也找不到他们, Oracle原厂的服务是他们出面请的, 那个费也没有给呢.

    其实直接说不付也行, 说公安系统要你免费提供支持也行, 这不接电话就不对了. 被迫免费也行啊, 谁让我们做技术的单纯, 容易被骗呢? 借那次经验, 完善了AUL恢复软件对于中文的支持, 也是好事, 解决了中文的问题, 繁体或韩文或日文都一起解决了, 也算有所得了.

    估计这一页或本站会被GFW掉.

相关文章 | Related Artiles

我要留言(当前4)

作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    今天收到一个恢复请求, 在QQ上和人聊了一通, 看情况是只有RMAN备份出来的文件, 没有数据文件, 需要恢复出数据来. 聊天内容如下:

d.c.b.a: 现在所有数据文件都丢了?
answer : 现在有的就是这些文件.
d.c.b.a: 要确定, 是不是全的, 最好是找出他们作备份的脚本看一下
answer : 这个恐怕很难
answer : 这个脚本是什么格式的?
answer : 一般存放在什么目录下?
d.c.b.a: 他们那边没有管理员的?
answer : 有，但是不能问...
d.c.b.a: why?
answer : 因为东西是down下来的. 明白了?

    这种事情当然是不能做了, 对方也知道说错话了, 马上就下线了. 从安全的角度来看, 数据的备份也需要分开来保存了, 以免人家轻松取得所有的数据.

相关文章 | Related Artiles

我要留言(当前2)

作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    公司运维部某未婚男生的感言如下:

    公司内部或外部的未婚女生, 回答一下吧.

相关文章 | Related Artiles

我要留言(当前2)

作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    作为DBA这样的后台运维护人员, 需要监控很多东西, 除了数据库及主机的健康状况之外, 更重要的是一些业务信息的监控. 平台不是重要的, 最重要的是先有内容, 下面就是一个用WebChart画出来的业务数据图, 可以看到在早上2点前后的10分钟业务量有一个突然下降, 等会上班后就可以去问原因了.

    很多网站应用都做成分布式的, 监控的内容还可以扩展到接口的调用, 及消息系统中消息的进入和处理量等.

    监控的目的是为了帮助我们及时注意到发生的事情, 并为之找出合理的解释.

相关文章 | Related Artiles

我要留言(当前6)

作者:d.c.b.a, 订阅AnySQL, Oracle数据库恢复及服务, Sybase恢复, 磁盘及RAID恢复

    ASSM虽然是9i就出现的功能, 但一直没有使用它, 也没有任何经验. 早上在检查执行成本有显著变化的SQL时, 发现一条Insert语句的单次执行成本只有以前的四分之一, 很奇怪一条插入语句的平均执行成本为什么有这么大的变化. 从Statspack的信息中用WebChart画了一个图.

    在上图中, 这个语句的表是按月分区的, 每天进入的记录数是相同的, 但物理读31号和1号截然不同, 可能是什么原因呢?

    在ASSM中虽然了减轻了DML操作对Segment Header的争用, 但增加了用于空间管理(Free List的替换方案)Bitmap区域, 这部份的读取需要代价, 另外记录会被尽量均分出去, 最近Insert的记录也不一定放在一起, 所以每次Insert操作都可能会发生物理读.

    除了这方面的问题, 记录的查询一般落在最新的数据上, 但由于使用ASSM, 最新的记录被分散的很历害, 所以查询的读也会比较多. 比如按时间去查询, 就是一个典型的例子, 用传统的Free List去管理, 情况会好一些.

    以上还只是一些猜测, 还没有将表移到非ASSM的表空间上正式对比过, 有空先测试一下好了.

相关文章 | Related Artiles

我要留言(当前5)