Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
在ACOUG年会前夕,我收到了邀约,还是去年的老传统,10分钟做一个分享。 距离上一年的分享过去了一年,也算是对自己的一个简单总结。上一次的感受可以参见。
问:如何生成一个随机的字符串?答:让新手退出VIM 。 生成一个随机数看起来很简单,一直以来却深知它的不易,怎么让一个确定的值得到一个不确定的值,这个想起来都有点困难,而且这部分内容,自己也花了些时间去看Java源码,结果发现远比自己琢磨的要复杂的多,加上也有些日子没写过Java代码,可谓是困难重重,写了一小部分的总结发现,竟然有很多不大理解的地方。
对于Oracle数据库的闪回区的设置,之前和一个同事和讨论过,总体来说有一些不同的意见。 首先这个闪回区是一个逻辑的概念,闪回区的大小不会严格依赖于磁盘空间的情况,比如磁盘空间目前剩余100G,但是你设置闪回区为200G是没有问题的。
自从有了Zabbix+Orabbix,很多监控都有了一种可控的方式,当然对于报警处理来说,报警是表象,很可能通过表象暴露出来的是一些更深层次的问题。这不又来一个,不看不知道,一看让自己着实吓了一跳。
在之前自己的一个测试环境中,因为本身磁盘空间不足,导致一个测试库数据目录溢出,最后花了点功夫,将一个2G左右的文件经过收缩的操作后,竟然收缩为7M。详情可以参考 收缩关于收缩数据文件的尝试(r5笔记第34天) 而隔了很长一段时间后,我在线上一个环境碰到了类似的问题。
在周五参加了公司组织的TB活动,虽然过去了快2天,心里还是有不少的感慨,可能有些思想会比较碎片化,见谅见谅。 最近没有怎么好好休息,忙起来发现有很多事情需要做,而突然闲下来发现好多事情没有做,就在这种纠结中过完了一个星期。
今天参加了中国软件技术大会,忙碌之余还是简单记录下自己的感悟。 首先,对于技术大会,我说说一些大家常犯的通病。 对于技术大会,如果去参加而没有一个很明确的学习目标,那么在技术分享中的收获就会少很多,很多人要么是冲着某一个专家去的,要么是冲着某一个主题方向去的,最好是带着问题去的,这能让你少走很多弯路,而且一个重要的环节是在分享后互动答疑,这种机会其实非常难得而目前却很容易被忽视。
今天看了一些12c的内容,有几点需要补充一下,以后也会不定期来推送一些12c使用中的总结。 是对于PDB的信息抓取,比如当前有哪些PDB,什么时候启动,容量大小等 每个PDB对应的会话连接有多少 查看AWR报告的一些感觉 首先前两部分的信息,使用show pdbs查看还是有一些难度,查看v$session还是有一些不大灵活快捷。
今天在测试12c的temp_undo的时候,准备在备库上测试一下,突然发现备库使用TNS连接竟然失败。 抛出的错误如下: $ sqlplus sys/oracle@testdb as sysdba SQL*Plus: Release 12.
有时候真忍不住感慨,中午出去吃顿饭容易吗?今天的真实经历让我开始了深深的思考,感觉就是一场梦,其实是一堂生动的生活实践课。 中午饭点时的惆怅 到了中午吃饭的时候,我总是会惆怅,去哪吃饭,去哪家吃饭,有时候就忍不住感慨,诺大的一片区域,这么多饭馆,竟然没有几家能去的。
下午一个偶然的机会听到了一首歌,让我一下子想起了在泰国出差的日子。这首歌曲让我我电脑前工作很长时间,在深夜,因为东南亚时差的原因,我感觉我好像多活了一个小时。有时候醒来是在沙发上,有时候醒来发现灯还没关,生活就是在这种随意而又忙碌的感觉下流逝。
记得有一天快下班的时候,一位开发同事找到我说,需要对一个表做变更,数据量据说有上千万,而当时是使用的MySQL版本是5.5,这可如何是好,对于在线业务要求高的情况下,这种需求真是让人头疼。
如果有些朋友还记得,在前不久自己还做过一个简短的计划。 近期的学习计划和目标 (r10笔记第71天) 当然计划付诸实践,确实要费不少的心,有些做到了,有些没有做到。
但凡是学习 过Oracle的同学,DBCA都是一个必备工具,有了这个工具,创建数据库成为可能。而DBCA本身有图形和静默两种方式。静默方式看起来高大上,可以轻松搞定一个看似很复杂的创建数据库过程,而只需要一个命令。
最近要迁移几套环境,涉及的数据库有Oracle,MySQL,数量还不少,能够达到的目标就是整合后的服务器缩减幅度达到70%,这样一种迁移场景,就涉及到很多的网络连接情况,如果本身业务优先级高,涵盖的是全局业务,那么这个影响就会无限放大。
昨天发现一个5.7的MySQL从库在应用日志的时候报出了错误。从库启用过了并行复制。Last Error的内容为: Last_Error: Coordinator stopped because there were error(s) in the worker(s).
一直以来,Oracle的发展是如火如荼,依然非常成熟,无论是行业的人员和资料的丰富程度。对于数据库的体系结构的内容,下面这张图我估计很多DBA都快看吐了,每次一提起体系结构,总是会看到这张图。
今天给大家爆发一下小宇宙,也和大家分享下最近的一些心理感悟和学习感悟。都是我看到的图片,觉得不错就拍下来了。 第一张是我在北京一中教学楼里看到的,这句话让我感触很深,为了拍这张照片,也算是花了些功夫才拍下来的。
在MySQL和Oracle中的delete,truncate还是存在着一些差别,明白了这些差别可能对于处理问题,理解问题会有一些帮助。 我们来简单通过一些测试来说明。
今天突然有了一些感慨,而在思考技术人生的时候,发现以前的一篇感慨文,原来我已经说过了那些话,现在读起来依然朗朗上口,感兴趣的朋友可以继续读读,大家一起聊聊。
一直以来,我如果去一个城市,当地最好的大学是尽力要去的,而这次恰好去了上海,我想复旦大学也不能错过,说复旦是上海最好的大学不知道又没有争议,但是在我的印象中真是一个非常不错的学校。
今天算是繁忙的一天行程,从北京到上海,飞机晚点从机场到达酒店已经是快凌晨2点的样子,而在酒店布置会场的社群小编忙到了快凌晨4点,非常辛苦。峰会今天的顺利举办和里面的严谨安排和他们有着很千丝万缕的关系。
昨天使用GoldenGate同步数据,数据量玩得有些大了。最后发现很多小问题变得更加严峻,比如空间问题。 而且由于没有更多的经验,导致这个问题被我引入了另外一个极端。
今天对GoldenGate的数据同步进一步做了测试,发现在一些模拟真实的场景中,需要考虑的因素要更多更为复杂。简单同步几条,几百条数据的测试同步做验证测试可以,但是很难测试出来一些潜在的问题,今天碰到了一些问题,基本都得到了解决。
今天测试了一下GoldenGate的复制,发现还是有不少的细节之处需要测试,保证可控,而下面做了几个测试也加深了我对OGG的理解。 默认是不支持DDL的,而线上业务的DDL也是完全可控的,在升级前几天可以冻结DDL,所以在线业务中还是充分利用DML的数据变化即可,不过这些影响还是需要测试到的,做到心中有数。
拖延症的我终于接下来第二篇数据库参数的分析。 数据库的参数分析一直以来是调优中的重要一环,而感觉有时候却感觉找不到一些方法,我分析了一下,还是蛮有意思。
对于数据访问层的优化,我简单总结了一下,其实里面有很多的点子现在想起来有一种灵光一现的感觉,但是真真切切的,里面有不少是之前公司已经做到了的,所以一个做产品的公司真心很伟大,而能够沉淀下来如此多的东西,那绝对是一笔非常宝贵的财富,对于公司,对于个人都是持久的财富。
今天试了下搭建GoldenGate,搭建的过程也简单总结了一下。 目前源数据库是newtest2 目标数据库是dataguru 都是11.2.
GoldenGate这些年在数据迁移中是大放光彩,简称OGG,对于很多DBA来说,学会这项技能也会给自己加分不少。 Oracle在10g开始推出的GRID的概念,分为了以下四个层面。
之前搭建MySQL环境都是使用公司内部使用的脚本,其实说实话屏蔽了很多细节,对MySQL的安装还是了解比较肤浅,今天有个MySQL 5.7的数据迁移的任务,也是为了熟悉安装过程就走了一遍安装的流程,整体和5.6差别不大,这里演示安装的都是Percona发布的二进制版本,和MySQL官方的是完全兼容,当然也揉入了Percona一些自己的东西。
昨天快下班的时候,突然开发的同事找我说有个紧急需求,负责这个业务的DBA同事回家了,想让我帮忙看看,运行个SQL语句,几秒钟就好。我一听,就本着人道主义的精神留下来处理,但是发现似乎留给我的是一个大坑。
昨天在微信群中有个朋友也是无意中问了一下,说数据库中的表字段想保持一种相对规范的顺序,怎么办?要知道Oracle中这个操作就比较纠结了,因为是按照追加的方式来处理的。没法在已有的字段1,字段2中间添加一个字段3。
最近迁移一台测试环境,准备整合到12c的PDB,常规的思路是用Datapump导出导入,对于数据较大的环境来说这个时间会比较长,为此自己也尝试先升级这个测试库,然后加入到CDB中去。
早上到公司的时候,电梯排队的人很多,这个时候我总是喜欢扭头去公司的图书馆里看看。发现翻翻看看书,就有了更多的想法,有时候很多想法是好的,但是行动起来步履维艰,一来要花很多的精力,而来时间上一笔不小的投资。
昨天晚上睡觉前升级了一套备库环境,比我想象的时间要长一些,下午就要升级测试环境,早上还在做最后的方案,感觉真是惊心动魄。 升级的过程让我有了两种感触,刚开始的做升级准备和正式升级的步骤时候,感觉升级12c真是一把利器,升级脚本有了不小的改变,都是使用perl调用来完成,比如这样的形式: $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql 可以开并行,默认是4个,最高是8个。
今天计划把一个测试环境升级到12c,为了练练手,先在备库上来做。数据库版本是11.2.0.3.0,计划升级到12.1.0.2.0。 为了不影响原有的测试主库,我在备库上做了Failover,两个命令下去就立刻生效了。
对于10g,11g,12c中的参数变化有时候感觉就是使不上劲,因为参数好像很多,但是了解的又很少。隐含参数经常是碰到问题的时候关联思考发现有这么一个隐含参数,有些问题可能有意识还会主动去查查,如果恍惚一下就算了。
Oracle的Data Guard技术再11g中有了Active Data Guard,就产生了很多的技术解决方案,比如读写分离,多活的技术支撑等。 12c 中又有了一些改进,那就当属Far Sync。
从开始使用12c PDB整合环境以来,发现确实不错,原来11g中整合的难题在这里得到了解决。 目前存在多套的测试环境,之前整合了一批,基本是采用整合schema的方式,但是后来发现这种方式局限性太大,最后就是如下图所示的结构,一半的系统整合完了,还有一半是保留了原来的样子。
继续前几天的一次性能调优,这次调优难度不小,而且空间很小,看起来简直就是绝处逢生的感觉。下面的两条SQL语句执行频率极高,每秒达到6000次,希望能够优化。 select companyname from license select supdepid from hrmdepartment where id ='' 前几天分析了一下,也尝试了很多种方法,但是始终无法启用索引,最后采用IOT的形式才看到效果,这是其一。
很就没写Java了,今天简单问了下行情,如今都是Java 9的时代了,老系统基本上都是在Java 7。 Oracle中很早就糅合了Java,Oracle 10g中自带Java 4,Oracle 11g中是Java 5,到了12c还是得与时俱进,是Java 6。
Oracle 12c中的PDB一下子让数据文件的格式复杂了一些,所以Data Guard就很有必要了,一旦出现问题,受损失的数据库是全局的。没想到在搭建Data Guard的时候还是碰到了一些小问题。
最近看到一个系统的负载比较高,引起了我的注意,查看AWR报告发现,竟然是因为两条很简单的SQL语句导致。 语句有多简单呢,就是下面的两个SQL语句。 select companyname from license select supdepid from hrmdepartment where id ='' 突然发现以前也发现了这个问题,但是最后也是不了了之,还是因为单纯从数据库的层面调整要灵活快捷的多,从业务层面来推动还是有一定的难度和阻力。
这部片其实很早就知道了,一直没有看到,实在遗憾,剧情是一个辣妹逆袭成为学霸,考上日本非常有名的庆应大学。我知道着了你片子肯定会带来更多的正能量,而且里面会有非常大的反差,逆袭总是一种新鲜的词语,但是逆袭有时候又好比是跃龙门,不是谁都可以,因为机会是留给有准备的人。
最近整合了几个测试环境,都放入了12c的容器数据库中。今天本来计划再整合几个测试库进来,结果因为碰到了JDBC的问题给耽搁了。 迁移数据库的步骤,因为数据量不大,数据结构较为复杂,所以直接采用了DataPump来做,而且因为测试环境,所以很多问题有充足的时间去排除和分析。
今天有个同事问我一个mysqlimport导入的问题,看起来还是蛮奇怪的。同事在客户端导入一个文件。文件大小是2.8G,然后报错mysqlimport: Error: 2013, Lost connection to MySQL server during query 对于这个问题我的第一感觉是一台云服务器,是不是没有配置swap造成的原因,因为在之前的一次迁移中,被这类问题折磨坏了,遭遇了OOM-Killer的问题,最后发现是swap没有配置导致的。
对于使用12c的PDB,如果想尽快熟悉,掌握,那就是和业务挂钩,让它跑在业务上。当然是在能够基本驾驭它的前提下,要不就真成了甩手掌柜。11g可以玩得很好,12c里面也差不到哪里去。
最近在整理测试环境的服务器资源,发现真是混乱,问题比较多。首先是服务器配置较低(很多都是KVM或者openstack虚机),资源使用率不高,有些数据的版本较低(10gR2),没有开启归档,没有备库(有些都是异机备份的形式)。
最近在服务器盘点的时候,发现测试环境还是值得整合一下,因为服务器资源老旧,整体配置不高,服务器资源使用率不高,业务要求不高,多个实例分散在多台服务器上,要考虑灾备,要么是每天全库导出异地备份要么是Data Guard,其实还是蛮适合使用容器的方式来管理的。
周五的时候出版社的荆波老师打电话告诉我,我的新书《Oracle DBA工作笔记》市场反响还是很不错的,不到3个月已经基本售罄,出版社计划重印一次,短短不到3个月的时间里重印,绝对是对我的信任和肯定。