Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
今天的形成算是满满当当,还是在新泽西周内活动,我简单记录下来,仅供参考。 小攻略 在我看来有几个小技巧还是值得推荐的, 一个使用漫游超人,如果你的手机开通了国际漫游,但是上网的需求比较大,可以通过网络视频,网路语音,消息来代替打电话,这样一来办个wifi盒子一样的东西(漫游超人)就方便得多。
我们知道在11g的环境中我们可以通过一些分析来得到DBCA的一些后台处理工作,有一点需要说明的是,如果一个12c的单实例数据库需要转换为12c的容器数据库,你去查看官方文档,会发现这是一个空白,不是做不了,而是里面有一些地方会干扰到你。
初始MySQL中的derived table还是在一个偶然的问题场景中。 下面的语句在执行的时候抛出了错误。 UPDATE payment_data rr SET rr.
最近碰到一个蛮有启发意义的案例。是数据库监听相关的,但是实际的原因却又出乎意料。 问题的反馈受益于开发同学,一个开发同学在lync上找到我,说现在一个线上业务的数据库访问有些问题,想问问我是否有什么建议。
关于Oracle的半连接,反连接,我一直认为这是一个能讲很长时间的话题,所以在我的新书《Oracle DBA工作笔记》中讲性能优化的时候,我花了不少的笔墨做了阐述,结果在做MySQL性能优化的时候,优化思路切换到MySQL层面,我发现要说的东西要更多。
数据架构是架构设计中很重要的一环,可能对于很多DBA而言,数据管理,数据优化,数据迁移类的工作居多,而对于数据架构方面的工作也会思考少一些,这方面就会薄弱一些。
昨天看了下Paxos协议,比我想象的要复杂。每次都没能耐着性子看完。但是隐隐感觉就跟钓鱼一般(尽管我没用真实试过),如果有耐性,能坚持还是能够明白的。 于是乎,我拿起了大学学习的一本算法书,突然发现里面有很多我早已忘记的东西,记得有一个算法我琢磨了好几天,结果老师上课几分钟就讲完了,所以大学里算法课真是让人费神的课程,工作以后算法自己去写的场景还是少很多,我们更多是去用,但是实际证明不是不重要,而是我们自己没有重视。
之前总结过一篇,是分分钟搭建MySQL MGR环境的,但是有一个地方还有待改善,那就是那个脚本仅仅支持single-primary模式,不支持多主模式,而官方文档中这部分信息还比较少。
今天参加了Oracle组织的亚太用户组领袖峰会,我所在的DBAplus社群派出了我,韩锋,高强,王朝阳参加了这次会议,总体来说还有很有感触的。好吧,我们被叫做四大金刚。
昨天的一篇文章,今天有不少网友向我确认一些细节,我想最近正好在看GTID的东西,可以揉在一起来说说。 GTID这个概念看似简单,实际上还是有不少的门道。
MySQL里面有一个问题尤其值得注意,那就是自增列的重复值问题,之前也简单分析过一篇,但是在后续我想了下,还有很多地方需要解释,一个就是从库的自增列是如何维护的,是否重启从库,自增列会受到影响。
QCon大会全名是全球软件开发者大会,从这个定位来看受益的群体会非常大,面对如此大的一个群体,技术分享难免就会碰到两类问题,议题方向多元化,议题内容众口难调的情况。
最近同事也问了我关于MySQL MVCC的一些问题,我觉得这个话题蛮有意思, 而之前似乎也没有总结过,就参考了一些资料,把一些内容摘录出来。 什么是MVCC 以下内容摘自:http://www.
今天整理MySQL的问题时,突然发现自己已经整理了不少内容,但是时间长了还是会忘掉,但是如果重新看起来,就能够马上回忆起来,常说的老记性不如烂笔头,就是这个道理,不要过分相信自己的记忆力,能记下来就记下来,留给以后的你来看,你会发现每隔一段时间就会看到不同的自己,有些原来的想法还是错误的。
最近也抽空帮一些网友解决一些问题,有些是Oracle,有些是MySQL,有时候虽然忙忙乎乎,但是解决问题之后还是很有成就感的。 今天来说一个蛮有意思的问题,听起来还很诡异。
昨天写了一篇使用脚本搭建一主多从的脚本之后,奇龙兄建议我看看sandbox的功能,可以秒级搭建主从环境,简单试了下,确实很好很强大。 环境部署其实很简单,如果有网络环境,直接cpan一个命令即可。
之前写过一篇分分钟搭建MySQL Group Replication的测试环境,如果我们在一台服务器上想搭建一主多从的测试环境,怎么能够分分钟搞定呢,其实稍花点时间写个脚本即可搞定,无非就是把哪些程式化的东西整合起来,化繁为简。
今天有个朋友问我一个SQL问题,大体是一个update语句,看起来逻辑没有问题,但是执行的时候却总是报错。 语句和报错信息为: UPDATE payment_data rr SET rr.
今天聊聊一点我的想法,最近有很多事情都赶在了一起,而且一件件事情本来不是很紧急,但是随着拖延,一再延迟,现在已经不能再拖了。所以我有时候会逼着自己往前赶的节奏,但是就这点精力,确实有限,所以我就在想怎么改进,哪些事情可以做,哪些可以不做,难免还是有左右手互搏的感觉。
昨天对Data Guard的归档压缩进行了一个初步的测试,我今天又做了一些补充。 1.昨天测试的是默认50M的redo,如果redo增大,在IO bound的场景中,是否有很大的变化 2.对于归档压缩来说,数据量如果增大,是否会有较大的抖动,昨天测试的是20G的数据量,初始化了50% 3.对于整个数据初始化的过程中,主备的延迟到底有多大,是否有延迟回落的现象。
如果需要把一台MySQL中的数据定期归档到另外一台MySQL历史库中,那么很可能会发现会有重复值的问题,导致数据导入会失败,而这个问题其实是和自增列的重复值有关,我们来简单看看。
下午走在地铁换乘站的长廊里,我走在前面,父亲跟在后面,我走着走着时不时回过头,我们就默默的保持着这样的距离。 我突然想,我在我爸的眼里到底是什么样的呢,如果我去问他,想必也得不到答案,有些信息还是之前妈妈给我们反馈的,这样我也就大体知道我们所做的一些事情在爸妈眼里的不同。
今天我们来看两张图,为什么要看,看完就就知道了。 我们来猜猜看,通过这个图能够读懂什么,准备好了吗? go 首先这是一张手机拍摄的图,看起来是一张很随意的照片,但是细看图片却发现有很多蹊跷之处,这是哪里,为什么要拍这么...
今天抽时间在整理一个关于MySQL和Oracle共同面临的问题,但是它们有着不同的解决方案,就是经典的partial write问题,我也看到网上有很多DBA在纠结,在争论,相比而言,Oracle这边更沉默一些。
MySQL里的double write是InnoDB的三大闪亮特性,另外两个是insert buffer 和自适应哈希,其实还有几个比如异步IO,Flush neighbour Page(刷新邻接页),这个和系统层面的关联性较高,所以三大亮点还是更有针对性的。
对于Oracle的闪回,很多朋友也问过问,到底是怎么玩的?如果自己做过一些闪回数据库的操作,就会发现这个功能非常强悍。 Flashback DML的操作其实还蛮容易理解的,但是Flashback DDDL那可就是另外一个level了,我们大概了解一下MySQL里面的闪回就会发现,真要实现无缝的全闪回,确实有很多的细节和场景需要考虑。
今天费了些周折,总算搭建好了MySQL源码的调试环境,主要的目的就是想在看代码的时候有一些头绪,让这些开发技巧派上用场。不至于盲人摸象一般的拿着命令肉眼扫视,当然对于代码至于能不能啃下来,那是另外一回事了。
今天来说说两款压测工具sysbench,swingbench,早些时候傻傻分不清楚,其实两个差别大了去了。 swingbench 先来说说swingbench,这款工具是Oracle英国的一个员工用Java开发的,没想到一下子成了压测Oracle的不二之选。
作为一个DBA, MySQL源码安装还是要做做的,虽然不是推荐线上批量安装部署,但是自己作为了解MySQL的一个学习过程,还是值得的。 相比商业软件来说,开源的这一点上就让人很羡慕,商业软件我们总是使用各种工具和底层原理去反推,探测,但是离代码还是有一定的距离。
XtraBackup是Percona推出的一款备份工具,算是对于mysqldump的一个补充。对于大批量数据的导入使用mysqldump会出现一定的瓶颈,这一点做过一些数据迁移项目的同学可能感同身受。
昨天花了点时间整理了下并行复制在5.6,5.7中的一些差别和测试,当然只是一个开始,因为里面还有不少需要完善的部分,总体的感觉来看MySQL 5.7里的并行复制改进很大,能够极大提高效率,充分利用资源。
对于主从延迟,其实一直以来就是一个颇有争议的话题,在MySQL阵营中,如果容忍一定的延迟的场景,通过主从来达到读写分离是个很不错的方案,但是延迟率到底有多高可以接受,新版本中的并行复制效果怎么样,在不同的版本中是否有改变,我们能否找到一些参考的数据来佐证,这一点上我们可以通过一些小测试来说明。
现在的日常生活,不花钱几乎是不可能的,我们生活轨迹处处和金钱挂钩,有的同学可能说我极短一些,睡了整整一天,不吃不喝,不也没花钱嘛,这个确实够没心没肺,但是还有房租啊,哦,你是买的房子啊,有没有房贷?没有?!土豪,我们做朋友吧。
今天翻看了下《高性能MySQL》,真是让人拍手称绝,里面的很多实战思路非常不错,各种问题分析如数家珍,如果是有一定基础的同学,看起来会非常不错。 当然里面提到的一个地方,感觉很有意思,那就是主从延迟的一个测算思路。
昨天使用gdb调试MySQL中事务临界状态的时候,发现其实有些场景可能比我想得还要复杂一些,所以我在昨天的测试中结尾也是快快扫过,但是表明了意思即可。这一点上我在后面会把Oracle的临界事务状态也拿出来对比一下,还是蛮有意思的。
有一个小问题可能很多人都想起过,那就是MySQL中既然已经有了binlog,为什么还需要redo,这个问题看起来好像很简单,但是细细品来,还是有不少值得注意的地方。
昨天有了第一篇的测试之后,仅仅是一个开始。 我接下来做sysbench压测的主要思路是根据现有的配置作出调整,能够持续性的优化和压力测试达到目的,而不是简单的去对比连接数在不同数量级会有多大的差别,所以你会在里面看到一些问题的排查,一些问题的解决,可能有些又不是压测相关的。
今天用了下新版本的sysbench,发现和早期版本的差别还不小,确实有不少有趣的地方,是的,我们继续测试下MySQL。 如果大家看过《高性能MySQL》这本书,就会发现里面对于基准测试的描述非常全面和专业,里面的测试场景都是基于早期版本,这个版本有一个不太方便的地方就是无法抓取到更细节的数据,只有平均值,所以要不需要定制脚本,要不就需要更多的测试场景和时间来得到一个报告。
在MySQL中如果要迁移一个表导另外一个服务器/环境中,常规的做法就是使用备份工具备份,比如mysqldump,然后拷贝备份到目标服务器或者环境导入。如果某一个表数据量很大,导出dump文件很大的情况下,使用导出导入工具其实会花费不少的时间.
转眼间,2017已经爬上了眉梢,在有序计划中,DBAplus社群北京站沙龙拉开了序幕。 沙龙的初衷之我见 沙龙活动不光是聚聚人气,我用三句通俗的话来解释。
对于很多线上业务而言,如果有新服务器,新的环境,新的业务,到底资源和预期的承载压力是否匹配,这个得用数据说话,或是通过严谨的论证来阐述。 比如一台新的服务器,一般都需要经过压力测试,我们也叫拷机测试。
今天按照计划,决定得总结下MySQL的参数了,说来想来,立即就做。 大体算了下,手头的环境主要还是使用了Percona分支,官方的相对较少,就暂且按照Percona的版本来统计参数的情况,可能和官方的会有一些出入。
最近接到一个数据库报警,让我颇有些意外,这是一个PGA相关的报警。听起来感觉是应用端的资源调用出了问题。 报警内容大体如下: 报警内容: PGA Alarm on alltest ------------------------------------报警级别: PROBLEM ------------------------------------监控项目: PGA:6118.6 这是一个12cR1的环境,是一套测试环境,确切的说是多套环境整合后的一套大的测试环境,里面含有近8个PDB,也就是之前的多个测试环境整合而来。
今天来简单说下两件事情。一件是地铁冲突,一件是游戏。 地铁冲突 第一件是昨天晚上睡觉前看到的小视频,本来准备早点写完笔记就睡觉了,没想到看了群里发的视频,让我怒火中烧,就是今天在各路视频,微博中开始“走红”的地铁辱骂男,当时感觉地铁车厢里的人都怎么了,怎么连劝架的勇气都没有,看到大家在微博平安北京上纷纷留言,在咨询,如果动手是否会对自己不利,大家的一个简单的总结就是 打赢坐牢,打输住院,虽然夸张了一点,但是不无道理。
简单来说,我们的父辈和我们之间大多还是存在代沟,尽管我们生活在一起,可能有时候却会经历不同的事情,思考不同的问题,或者同一个问题可能有着不同的出发点和解决方法。
Oracle 12c中DBCA有一个特性看起来蛮有意思,就是直接通过DBCA来搭建Data Guard,当然这么说也有点噱头,我们来实际看看。 Oracle提供的官方命令结构如下: dbca -createDuplicateDB...
对于很多Oracle DBA来说,12c最期待人心的就是12c Release 2的发布了,而Linux64位版本的发布则是一个重头戏。详情可以关注公众号dbaplus来了解一下,今晚零点即将发布,可以尝个鲜。
MySQL中的undo截断还是一个很不错的特性。这让我想起了很久以前看到一个诺大的ibdata,但是却拿它无能为力,想把它收缩唯一的办法就是重建或者重构数据。 Oracle用得久了,总会有一些想法,看起来很平常的技术怎么在MySQL中却无能为力。
对于Online DDL,之前简单分析了一些场景MySQL中的Online DDL(第一篇)(r11笔记第3天),其实有一个很关键的点没提到,那就是online DDL的算法,目前有三个操作选项,default,inplace,copy可选 具体可以参考 https://dev.
最近周末时间终于是自己的了,生活的重心就一下子放在了家庭和孩子上,这么想的时候,胳膊还隐隐发酸。 家里的事情这两个周末也有所进展,孩子方面我也花了不少的心思,没错,今天是要说说我家珊珊,一个风一样的孩子。