Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
之前写了一篇浅谈事务(一),算是对事务的一个基本认识,今天来简单总结一下事务的隔离级别,虽然是老掉牙的知识点,重温一下还是值得的。 在MySQL中基本有这两种事务隔离级别的设置,默认的RR(Repeatable-Read)和实际中常见的RC(Read-Committed)。
到了周五,也就意味着一周的工作是告一段落了,似乎有些失落。 其实有时候也蛮讨厌现在的自己,看起来好像很努力,但是感觉动力不足。这种状态其实是非常可怕的。
前几天分享了下搭建MySQL Group Replication的脚本,其实感觉还是不太踏实,虽然我成功搭建了3个节点的环境,但是有不少问题还没有解决,甚至是特意避开了。
今天来总结下MySQL 5.7中的一些问题处理,相对来说常规一些。搭建的过程我就不用多说了,昨天的文章里面可以看到一个基本的方式,在测试环境很容易模拟,如果在多台物理机环境中搭建是不是也一样呢,答案是肯定的,我自己都一一试过了。
最近看了下MySQL 5.7中的闪亮特性Group Replication,也花了不少做了些测试,发现有些方面的表现确实不赖。当然要模拟这么一套环境还是需要花不少的功夫的,一般来说都是3个节点的环境,实际中要找这样的环境也不是很容易。
最近看了下MySQL Group Replication的内容,因为发布的时间不是很长,可以算是一个新鲜玩意,而且因为它特有的意义,这个特性显得更加意味深长。 我接触Oracle的时间要长一些,所以很多时候都喜欢带着对比的眼光来看,单着自己尝试着用了下这个特性,感觉一下子让我找到了当年学习Oracle 10g RAC时的感觉,里面还是有一些小问题,而且还不少,眼巴巴的看着报错,但是日志又很有限,查阅资料,竟然不是bug就是找不到一些相关的信息,所以有时候有种信息孤岛的感觉。
最近读了一些书,几乎都是在地铁上,下班路上读的,差不多两个星期的时间里,阅读时间就达到了近30个小时,所以你说没时间没时间,时间就在这里。 那么谱儿已经摆出来了,到底读了些什么书呢,这个还得好好唠唠。
行值表达式也叫作行值构造器,在很多SQL使用场景中会看到它的身影,一般是通过in的方式出现,但是在MySQL和Oracle有什么不同之处呢。我们做几个简单的测试来说明一下。
闪回数据库这个特性在很多Oracle DBA眼里就是鸡肋特性,因为谁会因为恢复数据而需要在主库闪回,最后可能丢掉更多的数据,这个观点没错。 但是如果是备库呢,这个特性就顺利成章的满足了绝大多数的恢复需求,无论你是truncate,还是一些drop table的操作都是可以轻而易举的恢复。
关于自己的生活,最近看了罗胖的《时间的朋友》,发现我们需要尽可能发挥有限时间的使用价值,时间匆匆,人生匆匆,关于现代管理学之父德鲁克的经典五问尤其触动了我。多少次蒙头思索没有答案,希望自己可以借着这几个问题来自省。
Oracle Data Guard中很可能出现延迟的情况,而数据一旦出现延迟就意味着丢数据。退一步来说丢数据总比数据乱了好,但是回过头来,能不丢数据但是丢了,这就有些说不过去了。
今天有一个数据库服务器报警,报警信息是来自于一个异机备库。可以看到这台服务器空间只有300多G,而剩余空间只剩下了不到30G.所以这样一个问题就很奇怪了。 这个服务器是否很老旧,答还在报修期内,其它配置也不差,一个配置较好的服务器怎么会只有300G左右的存储空间。
前几天有个同事碰到了一个MySQL数据恢复的问题,他运行了一条update语句,结果忘记了加where条件,结果等反应过来已经晚了。我简单确认了下,是否存在备份,没有,是否开启了日志,没有。
在之前简单分析过一个12c中数据字典的小问题。 Oracle 12c数据字典的小问题(r11笔记第49天) 最近查看邮件,12c的一个PDB还是存在JOB运行异常的情况,因为是测试环境,不是业务类的JOB,这个问题就给了我一些时间来修复。
关于MySQL的复制架构,大体有下面三种方式,异步,全同步复制,半同步复制。 三种复制方式 第一种是异步复制,是比较经典的主从复制,搭建主从默认的架构方式,就是属于异步的,相对来说性能要好一些。
很久没有去过电影院了,贺岁档的电影也不少,如果让我选择一下,本来是更倾向于看周星驰的新片的,但是让我有些意外的是,这个片子评分竟然不是很高。我对看片子的评分要求还是蛮高,所以思来想去,就去看了评分较高的一部动画片《了不起的菲丽西》,总体来说没有让我失望。
微信近几年进入了大家的视野,然后发展势头一发不可收拾,现如今已经形成了一个庞大的生态,当初看好还是看低,现如今已经经受了时间的考验,站稳了脚跟。举一个最简单的例子,今年过年拜年,除了个别亲戚朋友电话拜年外,剩下用短信拜年的我估计都是个位数吧,我个人今年只收到了一条拜年短信,剩下近千条都是微信中接收的。
今天在火车上接到一个电话说,数据库有个报警,让我看看是怎么回事。 看着报警信息一直重复出现,看来是有些问题了。 这是一个统计库,出现了DG相关的报警(自定义配置的),看起来是备库端接收归档的时候出现了问题。
此时,我已经踏上了从西北返往北京的列车,此刻,我正在上铺打开电脑,慢慢悠悠的开始今天的总结。 是的,我又要回到帝都来吸霾了。 这次我是一个人返程,父母还暂留陕西,妻女暂在甘肃,我们还有一个短暂的分别后就会重聚。
有句话说得好,百善孝为先,这个可以见得孝敬是如此的重要。而在处理很多层复杂的关系时,我总是会不由得想到这句话,有时候就会有些迷茫,有时候就会有些失落。无论如何,这真是一个很难的问题。
今天又出发去了陕西的景点,不说是西安,因为我们去了宝鸡,然后在几个县城的景点间奔波。 首先在大早上出发,赶到了太白山脚下的眉县,开始泡温泉,一直以来没试过,要体验就体验最好的。
今天开启了西安旅游模式,因为在我的眼中,十三朝古都肯定有说不完道不尽的故事,如果单纯说景点,可能很多时候论风景,论规模和现代的景点差距都很大,比如北京的圆明园,颐和园,论风景可能比很多现代的公园还差很多,但是里面有浓浓的历史痕迹,让这些一石一木都别有风情。
今天踏上了“回家”的旅程,说是回家,其实没有回老家,而是去了姐姐那儿,陕西西安,和父母汇合。 早些年来过一次十三朝古都,当时是姐姐结婚,来也匆匆,去也匆匆。
快要过年了,很多工作都会放下来,很多计划都会搁置下来,节前的检查还是必要的,尤其是那些看似不起眼的问题尤其需要注意。今天就处理了一起,也算是假期前的性能优化临门一脚。
最近偶尔会收到一个报警,提示一个Scheduler Job运行失败了。这是一个12c的环境,启用了容器选件,所以一个CDB会含有多个PDB。 如果你要说这个CDB,PDB的区别和联系,那我就直接上一张图。
今天翻了下日历,我的女儿二三事的小系列已经写了四篇了。 这几个月以来肯定还是有很多要说的事情。 这次我就来说点不太好表达的一些话题吧,比如孩子便便,性别,和孩子斗智斗勇的话题。
快过年了,很多系统都要进入最后的检查和复验阶段,一方面在节假日前,提前发现问题总比过节的时候发现要好。另一方面如果出现故障的时候能及时进行处理,这个时候我们就需要有一个尽可能全面的元数据收集。
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆ 今天多次被朋友的热情和感谢一波接一波“侵袭”,我觉得发个朋友圈肯定不过瘾,今天就容我炫炫富吧(先说没买彩票,和金钱无关)。
横道世之介 一部让人感慨万千的电影,
如果一个大表要抽取数据导出成csv文件,我们有什么策略,如何改进。 一、问题背景 今天开发的同学找到我,他们需要做一个数据统计分析,需要我提供一些支持,把一个统计库中的大表数据导出成文本提供给他们。
一直以来要做性能分析的自动化工作,但是久久没有动笔,今天索性来更新一版。 首先我希望得到的一个基本效果就是后台去扫描数据库的DB time,如果超出了阈值,比如这里我设置的为400(即DB time为400%),则会开启自动诊断的任务。
今天下午我的一个朋友碰到了一个Data Guard的问题,大体是主备网络出现问题,因为环境中配置了自动切换,结果备库就自动切换为了主库,这样就成了“双主”,我帮忙看了下,对备库做了闪回,然后直接转换主库为备库角色,一个看似繁琐的修复工作就完成了。
大概在2年前,我写过一篇文章,当时也算是随感。由Gavin King的故事所做的感悟 (r4笔记第24天) ,年轻嘛,都是意气风发,想好好撸起袖子大干一场。
继续前几天的一个案例一个SQL性能问题的优化探索(一)(r11笔记第33天) 如下的SQL语句存在索引字段CARD_NO,但是执行的时候却走了全表扫描,因为这是一个核心表,数据量很大,导致数据库负载很高。
今天本来是处理一个简单的故障,但是发现是一环套一环,花了我快一天的时间。 开始是早上收到一条报警: 报警内容: CPUutilization is too high -----------------------------------...
11年前的一个下午,我在电脑上敲下了下面的文字: 2006-09-28 17:07:13 曾经自己还是一个很菜的人,特别希望能够拿一把吉他在草地上弹唱,那种感觉特别的向往 ,在大一的下学期的时候我硬是咬着牙去买了一把吉他 ...
今天来点有趣的内容,可能比较烧脑。是四道有意思的题目,来看看大家的数学是不是体育老师教的,当然答不出来就玩个热闹,如果觉得简单就在文章末尾留言,让我们一起膜拜一下。
到了年底,有个好消息是今天是今年最后的一天雾霾了。 最后一天最会让人充满期待,很多人说又到了拿出前年的计划来看看的时候了。虽然有些打脸,但是我还是拿出了写在2016年初的计划。
之前写过两篇日本电影的推荐,如果我不去搜索都要忘记了。 值得推荐的几部日本电影(一) (r6笔记第11天) 值得推荐的几部日本电影(二) (r7笔记第79天) 今天继续推荐几部日本电影,也算是假期的预热吧。
ssh命令其实用了些日子了,但是感觉长进不大,主要原因是对它不够了解。 我想绝大多数的系统环境我还是使用ssh的方式会多一些,就这样看起来小米加步枪的工作方式,想想远离图形界面工具管理数据库也有好几年了。
今天开发的同学小窗口消息给我,向我咨询一个ORA错误的问题。 错误代码是ORA-30036,使用oerr ora 30036查看,由于是undo空间无法扩展导致。
昨天写了篇分析sys的文章,用Oracle的眼光来学习MySQL 5.7的sys(上)(r11笔记第24天) 收到了一些朋友的反馈,还不错,今天继续努力,再整理一篇。
sys的初衷 MySQL 5.7的sys自从推出以来,整体的反响似乎没有预期的那么高,而我看到这个sys库的时候,第一感觉是越发和Oracle像了,不是里面的内容像,而是很多设计的方式越来相似。
对于闪回部分,Oracle本身提供了非常多相关的特性,我个人对于闪回数据库这个特性最为喜爱,尤其是应用再Data Guard环境中,真是一大杀器。 而对于DML的闪回部分其实也相对比较容易理解,毕竟就是原操作的逆操作,之前通过logminer的方式来读取redo来间接得以印证。
不知道大家在数据库运维中是否会有这样的困扰,一个数据文件里没有多少数据,但是数据文件的大小却调不下来,尝试使用resize来调整屡屡失败。如果一个数据文件里有很多的小表,存在大量这样的碎片表,虽然我们从前端看不到,但是如果查看存储结构就会发现还是挺混乱的。
今天开发的一个同学问我一个MySQL的问题,说在测试数据库中执行一条Insert语句之后很久没有响应。我一看语句是一个很常规的insert into xxx values形式的语句。
今天解决了两个蛮有意思的MySQL问题,简单分享出来。 首先是昨天说的级联复制的情况,因为架构做了调整,我们要删除其中的一个中继节点(新加坡节点),而直接使用北京节点去连接北美的节点。
最近开发的同事反馈了一个问题,说有一台北京节点的MySQL数据库数据延迟太大,想让我们帮忙看看怎么解决。 这个问题一下子让我想起了之前“水深火热”的日子,因为这是一套MySQL级联复制的环境。
今天有个同事问我一个数据库的问题,如果开始他就把环境细节全都告诉我,可能我就知难而退了。等我大体明白了问题之后,发现好像背景比我想的要复杂多了。这是一个远程云主机环境,windows系统,运行着MySQL,在查询表时出现了问题,而且开发同事经过了repair也没有修复,说会卡住没有响应。
说到闪回日志,我们都知道闪回日志中记录的都是逆操作,那么就有两个问题需要解释了。 闪回日志和回滚段保存的数据有什么差别? 如果做了truncate操作,闪回日志是怎么记录的,怎么能够通过闪回恢复数据。