AnySQL.net

连错库误删100多张表

    炎炎厦日, 容易让人头脑发晕, 做错事情. 某地某位开发人员连错了数据库, 本来要连到测试库进行表重建的, 连到了产品库, 过了几分钟后, 猛然惊醒, 已发现删除了一百来张表, 业务立马被中止, 一堆人被拖到惊惶失措中.     在事件发生后, 立马联系本站, 决定用AUL去恢复数据, 事发情景如下: 1, 事发后立马停止数据库. 2, 数据库在归档方式下, 删表归档文件还在. 3, 开发人员可以提供准确的重建表的语句. 4, 数据文件有十多GB, 有五万个存放在LOB中的图片.     了解上述情况后, 立马让客户准备远程连接环境, 先是拷贝AIX上的数据文件到Windows上, 由AUL进行跨平台恢复; 然后是将Windows机器挂到Internet上, 由我进行远程操作; 约好晚上八点半开始, 经过三个小时的紧张恢复, 数据全部搞定....

Posted on July 6, 2008 3:02 PM

不能删除物化视图?

    几分钟前一网友问我如何删除一个实体化视图, 当然不是什么语法不会的问题了, 是发了Drop命令后一直挂着, 几个小时都没有结束, 你可以想想为什么? 先看一下创建的语法. create materialized view  user_order_mavi      build immediate        refresh   on commit        enable query rewrite as select  service_id,substr(user_isdn,1,7),          bill_type,follow_action,count(user_isdn)   from user_order group by service_id,substr(user_isdn,1,7),           bill_type,follow_action     看到这个语句, 应当是刷新的类型那儿有问题, 在ON COMMIT刷新模式下, 如果基表的DML很频繁, 会造成刷新很频繁,...

Posted on January 17, 2008 12:44 PM

难以忘怀DBA误操作

    最近流行自我恢过, 有人在ITPub上有人问DBA生涯中最难人忘怀的误操作. 最常见的有如下几类:     rm误删除文件, 解决办法可以参考Fenng的贴子, 这其中良好的习惯和权限管理显得很重要, 必要时写些角本来进行删除操作, 不容易范错.     连错数据库, 这种事发生的事也比较多. 如要连Standby的连到Primary了, 结果将生产库关闭了(这事这儿也发生过). 要连本机的连到生产库了, 要连测试库的连到生产库了, 连错库后用初始化角本去初始化造成了大问题.     拷贝粘贴问题, 很习惯将命令粘贴到窗口中去跑, 结果拷的不是想要跑的命令, 而是拷了错误的DROP或TRUNCATE命令, 这个错误我也范过, 还好只是得到一堆ORA-00942(表或视图找不到)错误, 后来就不这么做了, 都是拷到一个SQL文件中, 然后cat检查一下再跑.     不够小心, 如要DROP以TEMP结尾的表, 结果忘了打最后的TEMP, 将正式表删除了.    ...

Posted on December 20, 2007 1:10 PM

SQL DBA兼管Oracle库

    前段时间, 一个澳大利亚的网友说他的Oracle库中某个表空间只留下了几个数据文件, 还能不能恢复. 在这儿不讨论如何恢复数据的问题, 要关注引起这个问题的根源.     根本原因是他们请了一个SQL Server DBA, 兼职(顺便)管管Oracle数据库, 当某些数据过时了, 要归档起来, 这个SQL DBA就将表空间从Oracle中删除了. 原因是SQL Server中是可以这样做的, 只要数据文件存在, 就可以挂到新SQL Server数据库中, 不幸运地是, 他这个猜测错了. 后来他们的客户再来要求查询过去的数据时, 就发生了这个问题.     有两个方面的问题, 值得思考. 从DBA个人角度来说, 不应当这么随便地只根据自已的猜测, 就去做删除数据这样的操作, 这个思界, Google一下, 有这么难吗? 如果DBA有这种想法或倾向, 那么你很难被大公司录用. 从公司角度来说, 让不懂的人去做重要的事,...

Posted on December 12, 2007 11:35 AM

删除4TB的表

    由于历史的原因, 居然有机会清理4TeraBytes大小的表, 而且这个表是在字典管理表空间(DMT)上的, 新建的都不会再用字典管理表空间了, 估计在其他地方是不可能遇到的了. 用最吐的CTAS方法将数据归档了一部份, 并重新设计分区的逻辑, 完成后就得将这个表删除以释放空间.     心中很是担心害怕, 不过也没有办法, 只能继续. 大致经过了如下步骤: drop index ...; truncate table ... reuse storage; alter table ... deallocate unused keep 2000000m; alter table ... deallocate unused keep 1500000m; alter table...

Posted on December 11, 2007 4:57 PM

使用图形工具, 极需要加强权限管理

    又见图形工具引起的灾难, 在PL/SQL中用SYS用户登录, 不小心把所有的视图都删除了.     我已经见过好多次OEM上误删表/用户/表空间的问题, 都是因为在图形工具上按错了键或点错了鼠标, 这些工具在有权限时, 要删除什么东西总是默认以CASCADE方式进行的, 因此才造成的问题. 在这个例子中, 后来发现不单单是一些视图没有了, 还有一些SYS用户下的系统表被删除了. 在运行catalog重建系统视图时, 遇到了以下错误. CREATE OR REPLACE VIEW exu81approle ( role, schema, package) AS SELECT u$.name, r$.schema, r$.package FROM sys.user$ u$, sys.approle$ r$ WHERE u$.user# = r$.role#...

Posted on November 14, 2007 9:01 PM

MyLOG程序对于Drop类误操作恢复的作用

    接到过几次由于Drop误操作引起的恢复请求, 在那种情况下, 最主要的问题是没有办法定位被Drop的表的Data Object ID的值. 由于Oracle在执行Drop操作时并不真正地对数据文件清行清理(这是我们能恢复的前提), 从儿当你的应用中有很多的临时表, 并经常Drop来Drop去的话, 在恢复时进行整个数据文件扫描, 会发现很多的Data Object ID, 而你不知道那个是包括了有用的数据.     事实上这种情况下, 恢复的主要式作是去验证这些Data Object ID是不是包含了真正的数据. 现在我们有了MyLOG, 到可以用来做这件事, 当前要求你能提供执行Drop误操作时所用的联机日志或归档日志文件.     在LOGTAB.TXT文件中加入下面一行: 9999,18,OBJ$,     在LOGCOL.TXT文件中加入下面几行: 9999,1,OBJ#,NUMBER 9999,2,DATAOBJ#,NUMBER 9999,3,OWNER#,NUMBER 9999,4,NAME,VARCHAR2 9999,5,NAMESPACE,NUMBER 9999,6,SUBNAME,VARCHAR2 9999,7,TYPE#,NUMBER 9999,8,CTIME,DATE 9999,9,MTIME,DATE...

Posted on June 2, 2007 9:51 PM