Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
前几天在做一次巡检的时候,通过top发现有3个进程占用的时间很长,之前也碰到过几次这种情况,但是排查发现是由于监控程序在运行,算是虚惊一场。 今天看到这些进程的情况,还是不能掉以轻心。
在工作中,可能会接触到很多的环境问题,对于权限问题,总是感觉心有余力而力不足,环境太多了,可能在赋予权限的时候会出差错, 比如下面的场景,数据都存储在owner schema上,如果要访问这些数据,需要创建一些连接用户,所有的操作不能直接在owner schema下进行。
在生产环境中,如果系统已经稳定,调优的空间就会越来越小,但是不代表没有调优的余地,可能工作的重心就会更加求稳,sql调优就是一项不间断的工作,很多工作还是需要前瞻的,如果等到问题严重的时候再紧急处理,提前的分析这些潜在问题就会让你不会总是心跳加快,两手冒汗。
图形工具在学习中一般是不作为推荐工具使用的,很多时候可能工作环境都是字符界面,远程连接,基本没有可能接触到图形工具,图形工具的好处真是一把双刃剑,功能丰富全面而且极其方面,这是优点也是缺点,如果一旦脱离了图形工具,可能就会发现自己会的东西越来越少。
在11g中,database replay是一个很重要的新特性,按照这个特性的说法,可以完整地捕获数据库的负载信息,便于在需要的时候随时重放。 使用这种方法,可以以二进制文件格式捕获 SQL 级以下的所有数据库活动,然后在同一数据库或不同数据库内进行重放。
设计模式中,工厂方法模式的使用还是很频繁的,但是似乎在工作中没有留意或者重视。 在各大网站中对于工厂方法模式的例子一般都是举女娲造人的例子,我就不做重复工作了,我觉得通过模拟oracle或者mysql的jdbc连接也是一个很生动的例子,我们完全可以通过工厂方法来模拟这种,对于不同的需求可以灵活的处理。
在之前的博文中分享了关于数据抽取流程的一些思路,整体来说,数据的抽取是辅助,数据的加载是关键。加载的过程中每一步需要格外关注,稍有偏差就可能造成数据的损坏或者丢失。
今天开发找到我,说有个问题想征求一下我的意见。 问题的大体意思是,对目前环境中的两个表,我们就叫做表a,表b吧,他说根据一个时间字段去判断是否为5天前的记录,但是这个字段不是索引列字段。
今天刚上上班,就接到客户的邮件,说生产环境中执行某一条delete sql语句的时间超过了3个小时。最后客户无奈取消了这次数据清理,准备今天在申请时间重做。所以希望我在下午之前能够调优一下sql语句。
今天和Oracle的一个资深前辈聊了下,聊了不少技术的问题,他也来了兴致,随机提了几个问题来问我,发现看似简单的问题还是有不少的干货,很多东西似懂非懂其实还是没有深入理解,限于篇幅,整理了一部分的问题,有些问题回答的对,但是感觉理解还是不够清晰深入。
关于uml的内容在大学的时候学习过,感觉是花拳绣腿的一些知识,想用但是限于自己的认知和经验,实在是很难运用,到了工作的时候,感觉不需要这些工作也照样能做得很出色,过度的自信就这样维持了几年,等到积累了一定的项目经验,对于设计的关注程度也逐渐提升,有时候想表达一些设计的思想,自己DIY的图表可能只有自己能够看懂,看一些设计思想中的图也是似懂非懂,看来刚学外语也是不够的,还得学习UML,无规矩不成方圆嘛,让UML来作为我们设计中的思想转化器。
与sql语句的简单对比 在第一篇中分享了一些MongoDB的基本知识点,因为安装运行其实都还是很轻巧的,所以对于大家上手来说应该问题不大,但是安装完成,数据库也可以连接了,但是MongoDB中是没有办法运行sql语句的。
大数据的概念炒了好多年了,很显然这项技术经受住了时间的考验,不是有些人想的那样华而不实,多年来总是伴随着Hadoop的身影越发壮大。 这些年来数据的增长量真是发生了天翻地覆的变化,原来大家过年的时候都会很认真的拍一张全家福,恨不得把胶卷能够正反两用,多存点照片,现在好了,手机各类终端齐上阵,微博,微信,图片,小视频,所有的数据真是应有尽有。
不知道为何,总是在搜索一些技术的东西时,在百度的推荐搜索里会出现王垠这个人,百度百科对这个人的一句话介绍就是退学的清华直博生,在无数次忽略之后,今天带着好奇想看看这个人,为啥这么和我有缘。
总是在内心深处说,不要成为技术的奴隶,但是越是这么提醒自己,越是发现自己已经是奴隶了,已经不能自拔,为什么呢,因为我已经习惯了这种生活,习惯了使用目前的这种思维来工作和学习。
nmon在平时的工作中可能会多多少少接触到,从sourceforge上能够下载到nmon的包。可能是有着IBM的血统,这个工具对于AIX的支持力度要大得多。 当然对于LINUX平台的支持已经很丰富了。
现在有一个需求,某个环境中存在两个用户,一个用户中存在物化视图,另一个用户中存在源表,根据业务的需要,需要做一种特别的物化视图刷新。 物化视图用户中的物化视图为CORP_NAME 源数据用户中的表为ADD_CORP_NAME 可能数据刷新是没有问题,关键就是在于CORP_NAME中的字段要比ADD_CORP_NAME多一些。
单例模式基本是学习设计模式的第一个模式,而且在工作中使用太普遍了,通用到我们感觉就应该是这样,但是如果真给你纸和笔,在5分钟内写出一个完整的单例模式,估计还是有不少人会中招。
在数据迁移中,sql*loader和datapump总是作为一些常用的数据迁移方案,自己在经历了一些项目之后,优点就不说了,说点这些方案的缺点,批评不自由,则赞美无意义,所以我在提出了一些失败错误的经验后,会在下一篇中给出这些缺点的解决方案。
说起排序,总是会想起大名鼎鼎的快速排序,等自己再次翻开快速排序时,感觉是很陌生的,从这个对比也能看出自己确实是已经忘记了曾经重要的日子。 快速排序使用了分治思想,分而治之。
在之前的一些博文中花了大篇幅介绍了采用外部表抽取的一些细节,可能细节到了,基本原理的内容还希望再补充补充。 采用外部表抽取数据的流程图如下: 大体标注了一下抽取的基本结构,我们会尽量保证不去碰原本的数据源,会创建两个临时的用户,一个是只读用户,这个用户上只有同义词,只具有数据源中的select权限。
昨天开发咨询我一个问题,希望我对下面的语句进行调优。 语句类似下面的形式 SELECT subscriber_no FROM SUBSCRIBER S WHERE SUBSCRIBER_TYPE = 'RM' and CO...
在之前的博文中分享过一个执行了两天的一条sql语句,走了两个大表的扫描,导致执行时间很长,通过简化sql做了不小的改进,今天我们来看看还可以做些什么。 上次简化后的语句如下:with tmp_logical_date as (SELECT logical_da...
今天想起一个几年前学习过的程序,是在《编程之美》中提到的,是作为当时微软的面试题,写一个程序来控制CPU的利用率保持在50%,进一步延伸,能够写出程序来画出CPU利用率的正弦曲线。
tomcat作为web服务器,想必大家做过web开发的都离不开tomcat了,值得庆幸的是tomcat也是开放源代码的,最近准备好好琢磨琢磨tomcat的源码,还没开始就已经感觉到不少的未知恐惧了,慢慢来把。
话说工作也好些年了,对开发技术,数据库技术也算有一些了解了。今天晚上本来想继续写一篇技术贴,但是突然闪过了这个想法,今天还是说说这个话题吧。oracle版本的变更 先说数据库技术,这些年oracle,sqlserver,mysql,nosql的数据库技术真是越来越火,大数据火了一段时间,这些年都是云的概念,数据库技术也跟着火了一把,技术就是这样,你不创新,不进步,就会把社会讨论,成为历史,如果你的创新不迎合大众的口味,也会被淘汰。
二分查找在学习算法的时候会涉及到,算是一个基本的分治思想,对于算法的实现大家也都是很熟悉的,但是这个时候真会犯眼高手低的毛病。不信你自己试试,看你能够在段时间内写出可运行的二分查找算法。
如果你得到反馈,数据库突然间性能下降了好多,希望你能够尽快的定位出问题来,有一些思路和方法可以参考。分别从数据库层面,系统层面来定位,但是个人感觉而言还是不够快和准。
java中的序列化是一个很有意思的接口,只需要声明而无需做额外的工作,但是在虚拟机内部却做了大量的工作保证了这一特点。只要对象实现了序列化接口,就会把它转换为一个字节序列,当需要的时候能够把这个字节序列完全恢复为原来的对象。
在之前的一篇博文中分享了通过java来格式化sql,http://blog.itpub.net/23718752/viewspace-1444910/ 今天突然想试试通过sql来格式化一把pl/sql试试,想起来容易,做起来难,自己捣鼓了半天,总算是弄出点雏形了。
周末刚过去,今天来到办公室做例行检查,就发现一条sql语句已经执行234841秒(65小时),已经两天多了。 查看了一下对应的Undo资源消耗,发现这个语句是最消undo资源的语句,一个sql语句执行这么长时间,同时对于cpu,IO都是极大的消耗。
经常在抓取一些sql语句的时候,得到的sql文本有格式的问题,如果尝试得到执行计划,每次都会费一番周折。 比如下面的sql语句,基本包含了常见的格式问题。第3行,第4行出现了断行,执行的时候就会报错。
关于计算机病毒,说起来内容就很丰富了,但是第一次听到关于oracle中的病毒时,却感觉很新鲜。这是一个蠕虫病毒,距离现在已经有10年了,但是现在看起来还是能够借鉴不少精华的东西。
任何软件都不是完美的,oracle也是如此,隔一段时间就会收到oracle的邮件说建议打哪些安全补丁什么的。新发布的产品都是release 1,比如10gR1,稳定版本都在10gR2 不要小看着两个大版本的变化,印象比较深的就是10g 10.2.0.1的安装包有大概600多M,但是在10.2.0.2.0的补丁包就比安装包还多,可见在产品线内做了很多的修改,才使得数据库越来越稳定。
今天下午收到客户的邮件,说有一个job在运行的时候报错了,希望我们能帮忙看看是什么原因。 ERROR: Caught en exception: ORA-12801: error signaled in parallel query server P130 O...
使用sql_profile来调优一些紧急的性能sql可以起到立竿见影的效果,如果sql语句本身结构就很清晰,简单,略作修改就能得到调优后的sql语句。 但是如果语句中含有绑定变量,如果要得到调优后的sql_id就有些困难了。
在oracle中可以使用pl/sql来实现一些复杂的功能,同时可以通过自定义的外部函数来实现很多丰富的功能,我们可以基于c/c++来写一些函数,然后把动态链接库放入ORACLE_HOME中方便直接调用。
今天无意中看到了谭浩强先生的>这本书,虽然c语言都是很多年前学过的东西了,但是看起来亲切,实际用起来陌生,很多的概念都已经很模糊了,记得上大学时老师特别推荐的位运算这一部分,自己这次又看了下,还是有一定的收获。
在平时的工作中,可能通过pl/sql传入参数来做一些特定的操作,参数模式一般有In,out.in out这几种 比如dbms_sqltune下的PREPARE_SQLSET_STATEMENT就包含了三种类型的参数 FUNCTION PREPARE_SQLS...
工作中可能会经常实用工具来编辑sql 文本,实用sql*plus来编辑的机会比较少,但是这些也是硬功夫,一旦有需要手工编辑,其实发现也是很容易的。 关于编辑使用的命令如下,其实看起来一大堆,主要的命令还是增(input)删(del)改(change)查(list),按照这个思路来看就会容易很多,有些命令也是选择性的使用。
临时表在日常工作中可能使用比较多,但是大家都对临时表相关的一些知识了解比较少。我们来简单梳理一下。 首先是临时表空间,临时表都存储在临时表空间中,对于临时表空间,从数据库中查询数据字典就能够很清楚的看到,临时表空间是nologging的,也就是临时表也是nologging的。
新年,给大家拜年了。祝大家工作顺利,万事如意。 今天照例简单检查了系统的情况,发现在客户的服务器在下午的3-5点这个时间段,数据库负载略有上升,但是幅度不大,因为生产的awr抓取频率是10分钟,所以还是能够通过awr分析出一些问题。
今天在无意中看到了java字符串的一些东西,发现和oracle比较起来还是有一定的意义的,但是发现知识点准备好了,比较的时候,每一处java的变更都得重编译运行还是不够直观,其实代码中变化的部分很固定,所以尝试写了一个简单的shell脚本来实现动态编译运行,使得演示也更加直观,使用Runtime.exec还是有一些限制。
关于足彩,自己之前也林林总总的写了三篇,不管怎么说,都是一种分析和理解,肯定没有特别的规律和绝技可循。 自己也在世界杯开始买足彩交了不少的学费,在这几个月的过程中自己也有一些自己的感悟。
之前有网友希望我对mysql的double write和oracle能够做一个对比,其实这种对比方式挺好,能够触类旁通,举一反三。不过限于本人水平有限,欢迎拍砖。 关于MySQL的double write是对partilal write的一个补充。
在之前的一篇博文中讨论了分页存储,http://blog.itpub.net/23718752/viewspace-1435671/ 今天看了下分段存储,尽管这部分内容都是大学的课程内容,但是感觉好像没学过一样:) 分段式存储管理系统中,会为每个段分配一个连续的分区,而进程中的各个段可以离散地移入内存中不同的分区中,这一点上所说的段和数据库中的段还是有着很大的区别,数据库中的段是可以包含多个分区的,各个段 说起分段就会联想到分页,在这一点上自己的认识也很浅薄,查找了下资料,个人认为下面的这段描述还是很到位的。
在之前分享过第一篇 关于操作系统存储管理和oracle数据库 http://blog.itpub.net/23718752/viewspace-1359146/ 感觉对自己来说是迈出了艰难的一步,操作系统的概念有时候确实感觉枯燥,但是细细品来,都是前车之鉴,很多的方法或者改进都是在碰到很多问题之后总结琢磨出来的,所以从某种程度上来说,操作系统的基础是很多学科的基石,oracle也在不断的改进,从它的发展中也能看到各种改进的痕迹,这一点和操作系统都是异曲同工的效果,这也是我尝试来从操作系统为主线联系数据的一个主要原因。
在几个月前写过一篇博文 MySQL数据类型 http://blog.itpub.net/23718752/viewspace-1371434/ 当时写完以后有同事朋友就提出了一些疑问,对于汉字在MySQL和Oracle中的存放情况希望我能够详细的说说。
今天查看生产某个服务器的负载的时候,发现内存的使用情况有些异常。 top - 12:00:08 up 15 days, 12:04, 13 users, load average: 63.
这两天抽时间看了下CPU相关的一些资料,发现越是去了解,自己越是陌生,CPU的发展史相当的丰富,不亚于计算机的发展史。总是有很多人在历史的长河中默默的奉献着。