Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
有时候在很多工作环境中,如果彼此几个机器的配置相似,我们就可以不用一遍又一遍的安装数据库软件了,我们可以为了更快的完成安装工作,在静默安装,图形安装的选择之外,还有克隆安装。
在之前的博文中介绍过如何通过exchange partition,split partition达到快速的数据切换,对于上百G的大表来说,速度都在秒级完成 对于大分区重新分区来说,上面的步骤已经够用了,但是对于数据清理来说,工作才刚刚开始,这是一种逻辑的数据清理,因为目前分区表中重新分区后没有数据,对于历史数据可以选择按照分区逻辑使用insert append的方式进行数据导入。
今天来到办公室,发现有一台服务器中的数据库实例停掉了。这种情况真是意料之外,尤其是我还不是很熟悉这台机器的服务。 赶紧查看数据库日志,可以看到数据库在昨晚停掉了,从日志来看没有人为的痕迹。
在上周巡检系统的时候发现session列表中显示有一个session的状态为“KILLED",当时没有太在意,等到周一回来做检查的时候,发现那个session的状态还是为KILLED. 这肯定是个问题,我们来看看这个session的情况。
在启动数据库的时候,open阶段总是可能出现各种各样的问题, 比如让人胆战心惊的错误。ORA-01113: file 1 needs media recovery 自己留意了一下,其实还是有蛮多的场景会出现这个问题,有些细节可能没有注意到就会出现这个问题,比如我们重建控制文件的时候。
datapump是在10g之后推出的新特性,无论从功能还是性能上,都有一定的改进,可以说在功能上丰富了很多,在性能上也提升了很多。可以说exp/imp中能实现的功能,肯定在datapump里面都能实现,而且大多数情况下效果还要好一些。
dataguard broker是在dataguard使用基础上提供的一个工具,可以把原本复杂的命令控制语句集成起来,比如switchover,failover等等,可能在多个备库的情况下需要敲不少的命令,这个dg broker的优越性就显示出来了。
目前项目中有一个问题,存在一个分区表,因为分区规则的问题,使得分区表中的数据分布很不均匀,数据都分区在了默认的maxvalue分区上。现在需要重新划分分区。从常规的角度来看,这中重新分区的问题一般有以下几个步骤。
选择就代表着放弃,同时放弃也意味着是一种新的开始,自己选择的路,对与错都要走下去。不去试怎么知道是对是错呢。对于生活如此,对于职场亦是如此,今天也在努力去回忆新公司的新面貌,新气象。
迷失这个片子,出了6个季,每季都差不多有15集左右,看这部美剧也是断断续续,其中还包括跳过了一些部分没有看,最近直接切到了第6季,然后花了好几周的时间才把它看完。
今天在做一些演示的时候,在虚拟机上装了两套数据库软件,10g和11g的。还是在演示普通数据文件迁移的时候还是碰到了一些意料之外的问题,从当时的情况来看感觉还是比较诡异的,所以马上切换到另外一套环境去试验就没有任何问题了。
提到shared pool,都会不由得和sql语句的解析过程联系起来,因为shared pool所做的主要工作就是解析sql语句,生成执行计划,在之前的两篇中对于shared pool的存储进行了简单的分析,在10g,11g都是保留了255个bucket,可见这个值还是一个最优的默认值了。
想最近写一篇关于感恩的文章,先在此酝酿一下,关于感恩还是感慨良多,我就再感慨一把吧。大家看完就别感慨了。 在人生的征程之中,会有很多的选择,似乎之前的几次工作离开都没有如此的沉重,可能时间呆的越长越有感情,需要感恩的事物太多了吧,越是难以割舍,越是发现需要感恩的地方太多。
今天和同事在太熟悉家常菜聚了一下,好久没有聚餐,也希望这种聚餐方式少一些,因为多多少少还是有种伤感离别的味道,期间自己也喝了一点酒,也是希望能够带着一些清晰的回忆来作为今后的一些记忆片段,而不是朦朦胧胧沉醉不知归路的感觉。
最近一个朋友想让我帮他一个忙,看似是一个很简单的小忙,就是出两道l题,一道可以难一些,可以通过这道题看出一个开发人员的数据库水平,sql或者pl/sql都可以,另外一道题需要是一道sql题,可以通过这个题目看出开发人员的sql水平。
关于数据库中的死锁。如果在应用中碰到都会毫不犹豫转交给DBA,但是从目前我接到的deadlock的问题来看,和Oracle官方的描述基本都是一致的。 The following deadlock is not an ORACLE error.
ASM自10g开始作为Grid的一部分,对于存储管理层的一个重大变革。重要性和丰富的功能就不多说了,主要的一点,是完全免费的。所以对于高端存储望而却步,而且不希望投入很多的投入在存储上,可以考虑ASM来很实惠的完成存储管理。
最近抽空练习了下手工建库,在10g的时候基本都在20分钟搞定,在11g中其实还可以更快,因为10g中需要配置的admin目录,需要创建bdump,udump之类的目录等等,在11g都被adr给默认替代了,只要提供了$ORACLE_BASE,就会默认在$ORACLE_BASE下生成对应的目录结构。
今天开发的同事发给我一个问题,在运行某一个Job的时候抛出了ORA错误,希望我们看看从数据库层面能不能发现什么。 错误日志如下: Function: EntitySQLCursor::query Line number: 113 ...
今天,数据迁移组的同事问我一个问题,说他们现在需要在迁移库中查看一些数据,但是查看的时候速度很慢,想让我们看看是不是数据库端出了什么问题。因为数据迁移的一些准备工作刻不容缓,所以需要我尽快进行分析和解决。
虽然闰秒的考验已经结束了,不少IT人都为这一秒付出了很大的代价。 我也是在周末知道闰秒的说法,自己听到时也是一知半解,原本以为是个很新鲜的名词,看着微信朋友圈和微信群里大家都在热烈讨论,因为都是oracle圈子的,大家讨论的更多关注点都在数据库层面了。
你可能 不了解的dump文件 在工作中,dump文件对于dba而言是再平常不过的文件了。不过因为dump文件是二进制文件,所以大家可能在平时使用中也不太关注,不过尽管如此,在导入dump文件的时候还是有很多的细节和技巧值得注意,可以避免一些不必要的问题。
关于tomcat源码的编译和环境搭建自己也是拖了一段时间,今天还是硬着头皮来做一做,还是有所收获。 tomcat源码的编译还是首选ant,作为apache的顶级项目ant,可以参见下面的链接进行下载,下载一个二进制运行包即可。
自己手头有一套dataguard环境,因为也有些日子没有用了,结果突然心血来潮准备启动起来学习一下,突然发现在敲了命令 recover managed standby database disconnect from session之后,命令运行正常,但是后台却报了ora错误。
作为DBA,经常需要在不同数据库环境间做数据的导入导出,exp/imp就是这样的轻便快捷的客户端工具,可以很方便的在不同数据库之间转移数据对象,即使数据库位于不同的硬件或者软件平台上。
在之前的两篇中分享了数据刷新的并行改进,其实在对很多的数据表做了切分之后,数据刷新的总体负载就基本是平均的了。如何使得刷新的过程更加平滑和完整,我们还是需要做一些工作的。
对于oracle来说,在除了EM,Gridcontrol之外还有什么其它的监控工具呢,可能precise也是一个不错的选择,前几天在论坛中看到一个哥们简单回复了ignite,自己也是好奇,抽空看了看ignite,还有的人回复TOra(http://torasql.com/download),简单比较了下这几个工具。
今天在上班的时候,同事突然发给我一个消息,说我养在办公室的鱼好像死了。其实他告诉我的时候是没有“好像”两个字的,但是我在内心做了一个过滤,好让自己能够勉强接受。
在之前的博文中分享了数据刷新中的并行改进建议,但是对于方案的落地还是有很多的细节需要实现。 首先是关于很多的表怎么把它们合理的进行并行切分。 根据实际的情况,因为这些数据字典表都相对数据量都不大,所以存在的分区表很少,所以可以考虑按照segment的大小来作为并行切分的基准。
在生产环境中存在着大量的数据,和业务是密切相关的。比如系统中的某个业务流程出现了问题,如果想复现就会显得非常困难,甚至是不太可能的,比如电信系统中存在着大量的客户信息,相关联的表的数据量都基本在千万,亿级。
前几天开发的同事问我一个sql的问题,目前在测试环境中发现这条sql语句执行时间很长,希望我们能够给一些建议,能够尽快做一些改进。sql语句类似下面的形式。SELECT /*+ INDEX(ACCOUNT,ACCOUNT_PK)INDEX(ACCOUNT_EXT ACCOUNT_EXT_PK) */ ACCOUNT.
在自己接触的很多的数据迁移工作中,使用外部表在一定程度上达到了系统的预期,对于增量,批量的数据迁移效果还是不错的,但是也不能停步不前,在很多限定的场景中,有很多物理迁移中使用传统方法还是相当不错的,传输表空间就是一个样例。
昨天同事找我,让我帮忙看两个sql问题,第一个问题是一个sql语句执行频率极高,但是目前的执行速度还是比较慢,希望我看看能不能调优一下。 另外一个问题是一个查询执行速度比较慢,但是执行频率不高。
之前在博文中分享过一个ora错误。 对于此,根据日志分析了相关的ora错误,但是从客户的角度还是希望能够提前做些什么,所以aio的设置就成为刻不容缓的一个任务。 但是对于aio的设置大家还是存在一定的分歧。
在几周前,某个测试环境在尝试impdp导入dump的时候报了错误,有个DBA立马做了kill session的操作,但是持续了5个小时,session状态还是KILLED,于是他们就在等待session被pmon回收。
今天晚上正在琢磨该写点什么,站在自己的书架前开始搜索,无意中竟然翻到了自己以前的学习笔记,发现以前还是很认真的。真是好记性不如烂笔头,自己当初记录的一些记录现在看来还是也还是有价值的。
继续昨天对于 ORA-00600问题的排查和分析(上)http://blog.itpub.net/23718752/viewspace-1696076/我们发现了一大堆的ORA错误。
昨天处理了一起ora-00600的错误,其中也经历了各种曲折,真是雾里看花,看透了之后发现很多问题都是有原因的。 起初是开发说有一个job运行的时候报错了,数据库版本是11.2.0.2.0 等到问题提交到我这,客户已经检查了一些信息了。
在很多的系统中,随着时间的推移,都会沉淀大量的历史数据。一般数据量达到一定程度都会考虑使用分区表来处理。根据业务规则,可能有些历史数据隔一段时间就需要做清理了,这个时候历史数据就需要在分区级进行清理。
在大量的分布式环境中,可能存在着大量的主机配置,ip配置,数据库实例配置,甚至操作系统用户,数据库用户密码也不同,这个时候如果记录在10条左右还能应付,但是如果给你几百个这样的环境,每次都需要先查找对应的操作系统用户,主机名或者IP就显得很麻烦,尽管已经设置了ssh信任连接。
今天晚上在台灯前看书,突然一个一个针尖大小的小虫子飞到了我的书上,我没有打死它,观察了它一会,看着它跟小苍蝇一样捋一捋腿,舒展舒展,就在书上爬了会,然后转瞬飞起消失在我的视野外。
有时候使用shell就是为了达到简化工作的目的,其实在shell本身强大的功能下,其实还可以更好一些,功能再好,如果界面有时候不够美观,清晰,效果也会受到直接影响,这种情况再程序员中尤为普遍,很多开发人员能够快速实现业务数据的处理展现,但是在美观上总是差一些,可能很酷的功能有时候就会因为界面的太简单,死板而大打折扣。
今天有个同事向我反馈一个问题,说是客户在部署他们提供的一个sql语句时,报了ora错误,想让我帮忙看看是什么原因。 update sub_errs set error_status = 'READY_TO_RECYCLE' WHERE sub_appl_id ...
接着上一篇的内容:半自动化运维之动态添加数据文件(一) http://blog.itpub.net/23718752/viewspace-1683250/ 我们可以通过监控表空间的情况,然后映射匹配文件系统中的挂载点情况,通过随机函数在各个分区中进行筛选,基本保证数据文件的创建能够分散到各个分区中。
在测试环境中,服务器和数据库实例真是多得数不胜数,自己也没有下意识去记住那个数据库实例在哪个服务器上,都是出了问题直接连过去解决。 这么多的数据库实例需要管理,表空间的监控是极为重要的,一般来说都会在给表空间设定一个阀值,比如说表空间剩余10%,20%等等,超出了阀值就会自动发送邮件,提醒DBA去做相应的处理,表空间监控如此,文件系统监控也是类似的思路。
原本dataguard中日志应用和数据库只读查询是一个互斥的关系,两者不能并存。如果需要应用日志,则数据库只能在Mount状态下 使用recover managed standby database disconnect from session来不断地从后台进行日志应用。
今天本来想继续一篇技术贴,但是今天有件事还是让自己印象深刻,觉得还是有必要写点什么,说得不对的地方,还是希望大家拍砖指正。毕竟写出来没有恶意或者针对性,只是说说我的想法。
最近携程的数据事故闹得沸沸扬扬,不管是什么原因,问题终究发生了。在问题发生的时候,更关键的是解决方法和防范措施,一般在升级或者重大的生产演练中,我们都有一个lesson learn,就是总结问题,总结经验,防范规范。
前几天同事问我一个问题,说在unix环境下有个目录下的文件/文件夹太多了,已经报了开始报系统错误了,客户希望能够定时进行这些目录的清理。 我连到那个环境去查看,ls都需要等待很长时间没有反应,最后尝试使用find命令,根据文件名来查找的时候反应才相对要快一些。
关于drop database在oracle中是致命的操作,这个操作自己在测试环境中体验过,会完全删除数据文件,因此这个操作非常敏感但是实用性不强,不过话说过来,这个操作也不是随便就能执行的,除了操作敏感的权限之外,其实还是有一些前提条件的。