聊聊DBA的那点事儿~
数
据库运维管理是个技术活儿，对DBA的要求也很高，不仅需要DBA有专业的技术能力，拥有非凡的耐心，还需要需要强健的体格。
那么，作为一名DBA，你都遇到过什么难搞的技术问题?有木有遇到过搞笑奇葩的经历？最后又是如何解决的？
对此，在我们的ITPUB论坛中，网友们纷纷讲述了自己职场中的经历。以下为小编整理部分网友的精彩评论，如果你也想和大家分享你的故事，欢迎来和大家交流。
你遇到过哪些奇葩的经历？
网友1983yu
难搞的基本都是那些ora600的错误，还有就是一些os，network相关的东西，因为不是很精通。嘿嘿，奇葩的经历不是很多，只记得遇到过一个同事做错了事情死不承认的，哈哈，本来没大关系的事情搞复杂了，最后还被开了。
运维这玩意就是要特别小心，小心无大错，另外要说的就是运维这个玩意不被人重视，好处轮不到你，坏处跑不掉你，优秀员工，高绩效之类的基本不要去想，哈哈~
网友ninipig
ORA-600的问题都很难搞，其中很大部分就是ORACLE的BUG，需要打补丁。
打补丁又有很大的风险，很容易挂掉数据库，很多时间打了补丁以后数据库就起不来了，单机数据库还好，RAC最容易出问题，很多时候都需要作回滚操作。
我的打补丁经验告诉我，打补丁之前一定要备份ORACLE的用户目录和软件目录，还要做个数据库的全备，这样一但打补丁损坏了数据库，还可以回退回去，不影响数据。
我觉得性能优化很难搞，其中90%都是应用厂商写的SQL太烂导致的CPU与内存占用率过高。优化SQL对我来说非常困难，我有五年没写过SQL语句了，基本上全忘记光了。
DBA经验告诉我，写SQL也算是写代码，DBA不仅要求你会写代码，还要求你能优化代码，整个一个高级开发工程师了。
还有10%是莫名奇妙的故障，只能提交SR，求助ORACLE原厂的帮助，而原厂一般又是让你关闭一个隐藏参数就处理完了，感觉有点治标又不冶本。
网友Big-Tree
Oracle难搞的是600，7445这种错误，dump文件要看，trace要看，还要查support，有patch的打，没patch的等或者Oracle给你个workaround。。。耗时耗力还不讨好。
Mysql难搞的就是莫名其妙，明明是这个错，他给你提示另外一个，还有，出了问题一查，这个暂时不支持，那个马上会支持，都去IOE呢，结果开发的也掺乎，用mysql好。真好吗？？
有次碰到一问题，开发说数据库连不上，去主机一查，本地都连不上，sqlplus一敲，马上cpu 100%，其他命令都一样tnsping, lsnrctl...各种进程都在呢，就是进不去，alert日志都不写了，一查，bug，db 10201，干干净净的，啥patch都没，打上patch好了。。
运维就是要运筹帷幄，有问题不可怕，致命的问题尽量提前规避，不影响的问题放后面，出来了去解决，要让领导知道，运维是活着的。
如果是新建的公司，尽量提前规划各种资源，未来3-5年都行，使用各种技巧说服老板。后面都想过好日子，你说呢。
关于数据库备份与恢复你有何心得？
网友ninipig
备份的话，日常工作用的是RMAN，周日做全备份，周一到周六做增量备份。
项目中用的是NBU备份软件来进行备份的，调用的就是RMAN的接口，直接用NBU连上ORACLE进行备份的，这样的授权很贵。
也可以让RMAN把备份文件备份到一个目录，然后NBU把这个备份目录里的文件以文件的方式备份到磁盘库上去，这样可以长久保存，这样的授权要比买纯的NBU 备份ORACLE的授权方式便宜不少备份一定要检验备份文件是否有效，不要哪一天数据库崩了需要恢复的时候，你才发现原来备份文件不可用就杯具了，看客户保留需要，至少备份文件要保留一周的。
我这里的备份是要保留2个月，也就是60天的备份，能恢复到60天。
另外校验归档文件的有效性也非常重要，如果中间一个归档文件损坏了，后面的一堆归档文件也作废了，因为不连续的归档文件，ORACLE在恢复的时候是不会应用到数据库上去的。
DG相当于一个热备分，有多余的资源可以搭建一套DG，一般来说来与主数据库的数据之差就是一个归档文件的内容，因为一般都是配置为最佳的性能模式。
网友Big-Tree
Oracle 做好rman备份，规划好增量备份策略，存储位置，这里面要计算好恢复可能需要的时间，DG可以搞，特别是11g之后，能省很多事。Mysql 做好全备，bin-log做好增量，按照频率和增长率规划binlog日志大小和expire时间。
网友1983yu
备份恢复这玩意估计要总体去考虑吧，单机，同机房双活，异机房双活，多活等等之类。就我用oracle来说一般整体备份恢复都是使用rman，exp，dp之类的都是只去处理一些数据，偶尔自己写点啥脚本处理数据，rac和dg之类基本能用就用上，安全第一。
你在迁移中一般有哪些迁移方法？
网友Big-Tree
=>Oracle 同平台的，10g，11g及之后，感觉mv是最快的，就是要小心创建控制文件的时候修改好语句。rman，expdp，exp那是肯定没问题的。跨平台，xtts，expdp都好用，若有多个cpu，expdp开parallel，也很快的。Mysql 直接dump出来，导出导入就好，全是sql语句。如果引擎不一样，要注意类型是否支持<又回到第一个问题了：）>
不管是谁不管是什么库，迁移前先备份，<可用的备份>。如果迁移失败，要能快速回退。
迁移时间段要选择好，不能太紧张，除非你测试的很完美<你自己信吗>。
迁移过程中要和其他部门配合的，提前定下来联系方式以及需要相互配合的地方。<你信不信有人玩失踪，睡过头了，手机没电了，"啊，没通知我啊">
PS：DBA就不能有追求么，DBA都是有追求的！
网友ninipig
迁移一般用EXPDP，省事，不费脑，就是有点费时间，比RMAN慢得多了，好处是可以垮平台，平时维护的都是AIX小机上的数据库，现在去IOE化很严重，很多小机平台上的ORACLE，都在往linux虚拟机上面迁移了。有时候导数据会遇到约束的问题，先让这些约束失效，然后导出数据，最后导入数据以后再让约束生效即可。风险是有停机时间。
DG也可以用在迁移上面，但是没有试过垮平台，因为做DG的时候，听公司高级工程师说过，DG的操作系统环境和数据库版本必须和原始库一致，不然会出一些异常问题。
这个不用停库，主库直接切过去就好了，只试过单实例做的DG迁移，RAC的没试过，不好评价。我维护的RAC数据库迁移全都是用的数据泵EXPDP导出来，然后SCP到目录机器上，再IMPDP导入到新的数据库里。
网友1983yu
我使用oracle做迁移一般都是使用dg去做同步迁移，然后备库转主库，不同版本不同环境我一般使用ogg去做同步，夸不同库的没搞过。再来情况复杂的就使用exp，dp之类，这个可能会出现各种状况，后续需要慢慢的修复。再最后就是上txt文本了吧，这种也是最慢最蛋疼的。。。
终极折扣进行时！盛宴，不容错过！
作为国内数据库与大数据领域最大规模的技术盛宴，2016第七届中国数据库技术大会(DTCC)将于2016年5月12日-14日召开。
大会云集了国内外顶尖专家，共同探讨MySQL、智能数据平台、数据治理、大数据创业、大数据深度学习等领域的前瞻性热点话题与技术，为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供最具价值的交流平台。
最后折扣期！4月20日前，订购DTCC大会门票可享8.8折优惠！团购更有折上折！
报名参会可直接点击阅读原文。
更多详情可访问DTCC 2016官网：
http://dtcc.it168.com/