|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
|
【内容摘要】记得以前我曾经写过一篇《年关临近 谨防数据库事故》，那的确是有感而发。 根据统计我们发现，每逢节假日前后，都是数据库事故多发期。 【内容摘要】这的确是一个惨痛的教训，大家在使用root用户登陆系统进行操作时一定要小心谨慎，能不使用root就最好不用使用。 【内容摘要】所以，做好数据库的备份是最基本的要求，除此之外，定期保存一下ASM Disk Header信息（通过kfed read来记录）以备不时之需也许是必要的 【内容摘要】本站从2008年开始提供各类数据库维护和咨询服务，有需要的公司可以考虑，服务有保障，运行才可靠。 【内容摘要】实际上，我们看到，很多误操作都极其低级，和技术能力基本无关，只是需要我们细致、严谨，再认真一点。 DBA有些素质是必需养成的。 【内容摘要】最好的做法是，远离对于字典表的操作，除非你真的认为你已经准备好了! 【内容摘要】注意到props$.value$列都被更新为ZHS16GBK,显然这是在一次不适当的更新操作中遗漏了WHERE条件。 所以今天我想提醒DBA们的是，WHERE条件很重要，在UPDATE时一定不要遗漏。 【内容摘要】有些习惯DBA必需养成，有些素质DBA也必需具备。 【内容摘要】SYS的对象最好不要轻易Move，出于谨慎以及对于DBA的基本要求，如果真要操作SYS对象，一定要做好完备的测试。当然数据库的备份是必不可少的。 【内容摘要】我们知道Oracle在运行阶段是不锁定spfile的，所以spfile的问题要等到下一次修改或使用时才能发现。 【内容摘要】如果可能，我建议Oracle将日志文件的扩展名改为.dbf 【内容摘要】断电对于数据库来说，绝对是一次灾难，断电之后系统、数据库能否正常启动都是个未知之术，所以对于一个业务系统来说，基础设施也一定要建设完善。 【内容摘要】Don't believe a customer when they say they didn't do it. Get evidence 【内容摘要】其实这个故障还是一个低价的故障，首先如果我们在不同的服务器上运行同一个脚本，严谨的做法是需要经过检查、测试，以确认其正常运行性，未经过测试靠猜想是不值得信任的。 【内容摘要】前几天写过一篇短文，有些习惯DBA需要养成，其中提到几点建议以帮助DBA减少错误。 【内容摘要】这几天，在帮助一个朋友进行数据恢复。 造成故障的原因很简单，因为维护升级时错误的连接到生产主机，结果导致生产库故障，数据文件被删除并部分覆盖。 【内容摘要】如果我一次一次的重复能够让所有的DBA们都记得，那么我仍然愿意重复我的DBA四大守则 【内容摘要】如果我一次一次的重复能够让所有的DBA们都记得，那么我仍然愿意重复我的DBA四大守则 【内容摘要】最近有几个朋友向我咨询Oracle产品的价格，我把一份Oracle的报价单放在这里，供大家参考。 【内容摘要】自信必须以扎实的底蕴以及丰富的经验为基础，一个好的DBA不在于经历多少故障，而在于有能够解决一切问题的信心，并且在面对问题的时候能够做出冷静而正确的判断。 【内容摘要】通常在一个企业环境中，都存在大量的数据库环境，这些环境怎样安装、管理和维护是非常重要的。 我们认为，规范非常重要，有了良好的规范才能形成有序高效的管理，这是我在每次讲座中几乎都会强调的。 【内容摘要】经常有朋友在ITPUB上问到DUL工具，我在这里对这个工具作一个简要介绍。 DUL是Data Unloader的缩写，为Oracle公司工程师 Bernard van Duijnen 开发，以标准C写成，可以直接从Oracle的数据文件中读取数据，转换为DMP或文本格式输出，在特殊情况下可以用来进行数据恢复。这些特殊情况主要指，数据库没有有效备份、或者系统表空间损坏，或者在非归档模式下的不可逆数据损失等等，一旦普通手段失去作用，DUL就可以作为最后一招来最大限度的挽救用户数据。 然而DUL并非一个商业工具，这个工具仅在Oracle内部流通，但是逐渐的，DUL也开始流入民间，被一些资深Oracle工程师所使用。 随着数据库版本的变化，DUL工具也在逐渐升级之中，对应Oracle8 / Oracle8i / Oracle9i / Oracle10g都有其相应版本。 作为DBA们首先应该知道DBA第一守则：备份重于一切。首先应该把备份作为数据恢复的第一手段。如果备份或其他恢复手段不可用，我们就应该知道，DUL是最后可以诉诸的手段。 国内的DBA专家DCBA自行开发了类DUL工具，他称之为 AUL 或 MyDUL，具有同样类似的功能，是非常优秀的一款国产软件。大家可以访问... 【内容摘要】题记:经常有朋友通过邮件向我咨询一些关于Oracle学习的问题，很多非常具有代表性，我在这里把朋友们的一些问题作些整理，并把我的回答公布出来，希望可以给大家做一个参考。 【内容摘要】最后仍然要重复之前那句话:无知者不能无畏. 【内容摘要】今天有朋友在ITPUB提问:请问sys.file$数据字典文件被truncate掉后是否能够恢复,具体的内容是: 请问sys.file$数据字典文件被truncate掉后是否能够恢复 昨天太大意了，一不小心把file$中的内容给删除了，造成tablespace里的数据文件列表看不到了，请各位大侠帮忙！是否能用那几个建库脚本将这个表的内容恢复？ 我们知道数据字典对于数据库来说至关重要,通常建议不要手工对数据字典进行任何修改和变更.因为一个简单的修改可能引发数据库内部很多潜在的问题. 除非在Oracle技术支持的指导下,对字典的手工修改实在没有必要.对于DBA来说,大家需要谨记: 绝对不要手工修改数据字典 如果发生如上意外(当然这个意外也太离奇了点),最好能够从备份中恢复(当然有些字典表是能够通过insert等简单操作恢复的),如果不存在备份,一个需要知道的经验是,千万不要关闭数据库,尝试导出数据,最后如果无法恢复,可以通过重建,imp导入数据恢复. 后来这位朋友电话给我,因为是测试环境,同时没有备份,我建议他导出重建数据库来解决. ... 【内容摘要】我们知道,在Oracle10g中,Oracle提供了缺省数据表空间的概念,即使用户不指定,Oracle也不会将用户数据存放在SYSTEM表空间,而且,Oracle还将一些无关紧要的系统数据分离到SYSAUX表空间,以使得SYSTEM表空间纯净化. 【内容摘要】前几天写过一则《DBA警世录:更新系统表(props$)修改字符集》，在Itpub开始了讨论之后，有朋友在没有仔细阅读的情况下，竟然在Oracle8i上尝试去试验，结果当然是数据库无法打开。 回顾错误的过程，这位朋友说： 我还以为 props$这个表可以在mount 下面update 呢 对"以为"这两个字，我是深恶痛绝的，作为DBA，一定要严谨，千万不能想当然。想当然的轻率对于数据库来说可能是灾难。 把这个故事记录在这里，为大家稍作警戒。 ... 【内容摘要】今天在Itpub上再次看到字符集变化导致的问题,作者给出的案例是这样的: 数据库为 9.2.0.7.0 ,OS : Solaris Operating System (SPARC 64-bit) 起因是这样的，我的一客户那里UPS出现故障导致系统宕机，然后起来，大约过了10来分钟，突然操作系统找不到磁盘又一次宕机，然后再起来，有用户报一个SQL用不上索引. 这个SQL是这样的： select * from ww.test20060504 dg where dg.user_number='7290' 第一个想法是给那个索引做分析，但还是不行，我们就对这个表做了一次分析，但执行计划没有什么改变... 【内容摘要】不断的看到很多DBA在学习或工作过程中犯过很多相同或相似的错误.忽然想到,如果我把这些常见的错误或者故障收集记录下来,做为《警世录》,那么大家是不是可以做为借鉴,并使得后来人少犯或者不犯这些错误呢? 这就是DBA警世录的由来. 今天看到有朋友记下了这样一个案例: 因为要导两个表的数据到测试库,结果在产品库上用了Truncate......更糟的是客户首先发现了问题 而不是自己 自己以为目标是测试库............ 总结:1. 谨慎&细心操作涉及产品库慎之再慎 2. 产品库和测试库有相同的user/pw(这在某种程度上造成了假象) ps:此次事件被定性为生产事故 严重 这样的案例很多见，因为测试环境和生产环境混淆而导致的误Delete,误Truncate操作经常发生。除了DBA不够严谨之外，制度上没有保证也是问题之一。 这位同学总结的很好，通常我们的测试库和产品库应该设置不同的用户密码，不同的SID，在进行重要操作时，应该先select instance_name from v$instance命令验证一下当前连接的例程： SQL> select instance_name... 【内容摘要】之前写过一个命题:列举你认为最重要的9个动态性能视图,在Itpub上有朋友忽然问这个问题答案.原来是在面试中被问及了这个问题. 实际上我提出的只是一个命题,答案肯定因人而异,而且这个问题的答案也无所谓对错.但是通过答案我们的确可以看出一个人对数据库的认识和理解,看出他的侧重点,看出他的知识面.进而,面试者可以通过你的回答进行更为深入的提问,从而来考察你的真实水平.在完善的面试下,真实的技术水平肯定是无法隐瞒的. 在命这个题的时候,我也没有想过自己的答案. 所以说9,是因为考虑到,数以1始,以9终,是以为极.故有9之说 如果真要我想,大约列了9个,真还不好取舍: v$session + v$session_wait (在10g里功能被整合,凑合算1个吧.)v$processv$sqlv$sqltextv$bh (更宁愿是x$bh)v$lockv$latch_childrenv$sysstatv$system_event 这是我的答案,这里有小惠惠的答案,大家都来列一下,我们取下交集或许可以给彼此一个参考:) 看到别人的答案我们应该思考:给我这些视图,我能获得哪些信息?我能解决哪些问题? 然后,如果有机会和答题者讨论沟通,必然有不错的提高,三人行必有我师,学习也正是一个不断借鉴交流提升的过程.... 【内容摘要】前几天给小惠惠出了一个命题:列举你认为最重要的9个动态性能视图(view). 为每个视图写一篇文章(不少于5页Word文档),说明从这个视图你能够获得哪些信息. 最后再写一篇文章(不少于20页Word文档),说明联合这些视图你能够获得哪些重要的数据库信息,并辅助数据库优化与诊断. 其实文章长短我并非在意,关键是你真的对这些知识作了思考,并且能够把这些知识运用到实践中去. 首先要自己思考,看看自己能想到哪些方面,然后再去参考别人的经验,看差距在什么地方. 比较然后学习. 同样的,最忌不作思考,直接去找别人的答案.这就如同我们解数学题一样,如果你偷看了答案,那么就会局限你的思路,很难再做出独立的思考和创新. 这样思考、比较、学习、总结，如是数番,我不相信技术得不到提高. 这个世界并不复杂,最怕你从不认真. 其实这文章、这题目是做给自己看的，而不是别人。... 【内容摘要】怎样获得/找到Oracle的Patch，这是一个朋友在Itpub上问到的问题。他还举了一个生动的例子: 比如我要使用oracle的全文检索功能，但是这个全文检索在9201里不支持中文，中文的无法检索，报错。但是在9206里可以，说明得打一些补丁吧？？但是用户不让把整个数据库都升级到9206，说担心稳定性，要单独只打全文检索的补丁，使之支持中文，所以我想知道怎么找到这个全文检索的补丁，这种单独的补丁在metalink里怎么找呢？ 我和他分享了一下我的经验，当然Oracle的Patch只能从Metalink上下载。关于Metalink请参考：Oracle初学者入门指南-什么是Metalink? 我一般先Search,Search文档库或者Bug,这些能定义非常多的查询选项一般就能找到Patch号 可以看具体版本修正的 Bug 列表,这个很容易找到 使用Patch的AD Search 功能 在不知道具体BUG号的情况下，通常方法2最容易和快速。Bug列表类似于:9.2.0.6 Patch Set - List of Bug Fixes by Problem... 【内容摘要】关于索引是什么的最简单的比喻是，索引之于表数据如同目录之于一本书。 通过目录的页码我们可以快速的定位一个内容，同样通过索引记录的rowid我们可以快速的定位一条数据。 【内容摘要】每个Oracle DBA都应该学会使用Metalink这个资源宝库。 【内容摘要】很多初学Oralce的朋友经常会问到一系列基础的问题,这些问题有的浅显,有的也许并不为众人周知,但是都曾经困扰过一群求知的朋友们. 从今天起,决定写一些浅显的基础的东西,一方面偷点懒,一方面可以为初学Oracle的朋友提供一些快速入门或粗略了解Oracle的便捷之路. 希望自己可以坚持下去.这个系列都将以:Oracle初学者入门指南为名. 新建立了一个分类,就叫做:Beginner. 我自己也正是这样一个Beginner. 开始这个题目是因为今天MSN上有一个朋友问到,什么是DSI?. 就把这做为第一个题目. DSI是Data Server Internals的缩写,是Oracle公司内部用来培训Oracle售后工程师使用的教材. 这样的文档上通常都印着:Oracle Confidential:For internal Use Only. 所以传播这类文档通常是为Oracle所禁止的,但是因为一些特殊的原因,这些文档在民间也多有流传. 你可以从Google找到一些相关信息.但是关于任何DSI教材的交流,索取都是相当敏感的. 很多人因为文档机密所以趋之若鹜,这也许是不适当的. 对于初学者,这些文档是不适宜的,因为从这里开始相对艰深,这些教材需要阅读者具有相当深厚的技术基础;初学者应该从基础学起,当你打好基础之后,也学有一天,你就可以来阅读这些文档.... 【内容摘要】经常有朋友会问，应该如何学习Oracle，怎样才能快速提高？我把自己的一点心得写在这里，供大家参考。 |
|||||||||||||||||
CopyRight © 2004 ~ 2008 eygle.com, All rights reserved.
|
||||||||||||||||||
