使用sqlplus的时候如果命令敲错之后,可能很多情况下需要重新再敲一遍,也可以用一些快捷方式,但是如果想查看之前执行的sql语句,list选项就无能为力了,它只能够列出上一条执行的sql语句。 比如下面的情况 SQL> select count(*)from cat; COUNT(*) ---------- 3559 SQL> select count(*)From cat where rownum<2; COUNT(*) ---------- 1 SQL> l 1*
主键和Null看似没有多大的关系,因为一般的主键设置都是not null,但是把两者结合起来,会有很多意想不到的情况,说是意想不到是因为结果不在预期范围,但是如果明白了基本的原理,整个过程又在情理之中。 我们先来演示一下问题。 首先创建一个表,创建唯一性索引。 SQL> conn n1/n1 Connected. SQL> SQL> select*from cat; no rows selected SQL> create table test(x number,y number); Table creat
datapump是在10g之后推出的新特性,无论从功能还是性能上,都有一定的改进,可以说在功能上丰富了很多,在性能上也提升了很多。可以说exp/imp中能实现的功能,肯定在datapump里面都能实现,而且大多数情况下效果还要好一些。 当然datapump相比exp/imp推出的时间还是要短一些,所以在使用的过程中还是或多或少碰到一些问题,还是在不断改进,而exp/imp绝对算是一款成熟的工具,从早期版本到现在都在支持,而datapump相比于exp/imp的最大差别就在于datapump是属于服务端的程序
对于Orabbix监控Oracle来说,它是提供了一个相对轻量级的客户端来综合监控多个数据库实例。从这一点来看,它的角色有点类似于工作中使用的SQLDeveloper或者toad这类的工具。 在之前的章节中,先花了些篇幅去比较zabbix和grid control,其实从功能上来看,基于zabbix的Orabbix的监控功能要有限的多。提供的默认模板中,监控触发器不到20个。 自己梳理了一下,默认的监控触发器在15个左右。 故障类型报警对应项错误类型报错简述数据库没有数据响应Oracle:aliveHigh
在使用rac的时候,有几个很闪亮的使用特性,一个就是load balance,这块毋庸置疑,确实做了很大的改进,从10g版本开始的多个vip地址的load balance,到11g版本中的进一步load balance改进 scan-ip,确实做了很大的简化。 而在failover的实现中,还是有一定的使用限定,比如11g中默认的scan-ip的实现其实还是默认没有failover的选项,如果两个节点,某个节点挂了,那么原有的连接中继续查询就会提示session已经断开,需要重连。 很多应用都在这样使用
zabbix作为系统级的监控还是非常给力,它总是在后台孜孜不倦的进行反反复复的检查和校验,然后通过邮件,短信,图形等方式来把系统的预警表达出来。 zabbix agent是在客户端上需要的一个组件,
在IT行业始终在进行着开源和商业的竞争而且双方火力都不差,开源的受众更多是中小企业,免费开源而且用户基数庞大,商业的用户都是一些大中型企业,求稳求成熟的服务。 今天来浅谈一下zabbix和Grid control,限于自己的认识有限,所以先开个题,zabbix也在熟悉和使用中,后续继续补全和更正。 zabbix大量在互联网企业使用,很大的一个原因就是MySQL所用,但是它的发展不止于此,对于系统级的监控也是很拿手。按照通用的说法,zabbix是基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源
在很多时候我们都需要做一些对比测试,比如我们的机器换了一个平台,比如机器做了较大的硬件升级和改造,或者引入了第三方的软件服务等等,很多时候就需要做一个基准测试,想根据测试结果然后对比做了一些变更之后,性能是提升了还是下降了,或者提升了,提升幅度有多少,这个单纯来估算一个值既不科学也不准确。这个时候还是想做一个基准测试,来得到一个数据报告,让数据来说话。 当然绝大多数的时候,如果想做这样一个测试,出发点是好的,但是说实话,落实起来真是难上加难,一来要推动业务部门配合,来从前端发起相应的数据处理请求,来进行基本
一般在一些容灾环境中,尤其是在11g的ADG非常普及的场景下,备库被赋予了更多的责任,很多时候在容忍一些延迟的情况下,有些应用的大量数据查询任务直接放到了备库,把它当做一个只读节点来使用,所以在有些情况下,可能备库的压力还是蛮大的。 最近自从把备库纳入zabbix的监控体系之后,有一个备库总是在午夜发来一条报警邮件。内容大体如下: adb0_s1@10.127.xx.xx_报警 ------------------------------------ 报警内容: CPU utilization is too
自己最近也在琢磨如何搭建出一个完善有效的运维平台,当然这个工作不是一朝一夕就能完成,前行的道路上肯定会有各种各样的困难和牵绊,但是自己还是能够学以致用,把一些重复性,繁琐性的工作都能解放出来,能够更加
在平时的工作中,如果接手的环境多了之后,每天去尝试连接服务器,都是例行的步骤,时间长了之后就会感觉这些工作都是繁琐重复的工作,其实我们可以尝试让工作更简化,更高效一些。 比如我们设定下面的场景, 我们存在服务器A,这个服务器可以连接到网络环境中的其它机器,我们假定这个机器就是中控机。 通过中控机连接到各个服务器环境,有下面几个步骤, 1)连接到某一台服务器B 2)查看系统的版本信息 3)查看系统的内核信息 4)切换到Oracle用户下 5)查看服务器所使用的Oracle版本 因为切换用户的原因,所以单纯使
从oracle中ASM的发展来看,到今天的普及使用,应该可以算做一种文化,因为这体现的不仅是ASM技术在实际工作中的成功普及,而且从某种程度来说,都代表了一个新生事物的发展历程,无论是java的发展还是各种开源项目的普及,都有着相似的痕迹。 asm从Oracle 10g版本推出,是作为grid的一部分鼓励使用的。而在这段漫长的时间里面,其实asm就在逐渐完善。 就如同你去公司内部推广一套很新技术的时候,人家肯定得衡量你的东西是不是足够好,如果性能指标能够达到指数级的提升,或者操作能够简化到极致,而且稳定,
在使用监控系统报警的时候,如果显示的报警信息为纯粹的文本,会枯燥很多,而且看起来很不清晰。 比如我们要监控表空间的使用情况,输出列有表空间名,状态,区管理方式,总共的空间,使用的空间,剩余的空间等。 如果显示成下面的形式,尽管在输出中尝试使结果看起来清晰一些,但是还是事与愿违。 showtsps:Tablespace: TEST_INDEX-->Status: OLN-->Ext_MGR: LOCAL-->Total: 301843.875MB-->Free: 30945.25MB-->Used: 270
很多事情见多了也就有了麻木的感觉,报警短信就是如此,每天总能收到不少的报警短信,可能很多时候就扫一眼,如果没有严重的问题自己是不会情愿打开电脑处理的。 对于此,有些朋友说是不是阀值太低了,调高一些报警就少了,如果那样做,监控的意义也就大大不同了。很多时候硬件错误或者系统错误不是突然出现问题,而是在一些异常的情况下运行,时间长了,难免出错,打个比方,如果两个配置一模一样的系统,一个内核参数有问题,资源使用有异常,总是CPU满负荷空跑,产生了大量的IO浪费,而另外一台,就是真正的空闲,负载不高,各项指标正常,那
在我们查看awr报告的时候总是会有一个关键指标需要注意,那就是DB time,这个指标一般都是通过awr报告来看到的。 比如我们得到的awr报告头部显示的下面的信息,我们就清楚的知道DB time是1502.06 mins,相对于Elapsed time来说,将近有20倍的压力。这个问题肯定需要关注。 Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -
今天也算忙忙碌碌,处理了不少小问题,自己也总结几个问题,本来写点MySQL和mongoDB的东西,发现还是没有准备好,再补补分享给大家。 ### 批量处理防火墙权限开通 每天都会接到不少的请求,有一部分是关于权限开通的,一般的流程就是登陆到目标机器,然后赋予相应的协议和端口,如果检查发现已经开通了权限,就不需要了。 所以如果要开通某个客户端的权限,可能对应很多台服务器,这样一来,处理工作就是大批量的重复性劳动,而且还繁琐。 所以磨刀不误砍柴工,先写个简单脚本来做个半自动化。 #!/usr/bin/expec
在数据库的运维工作中,如果有一种运筹帷幄的感觉,那么其中一种方式就是看报表,比如喝着咖啡缓缓打开电脑,几十台,上百台的机器的负载明细都在眼底。如果某个地方出现了异常或者明显的抖动,在报表中也能够很清晰的显示出来。 目前这种情况还是很难实现,但是我们可以创造,之前的博文中也分析过了zabbix+orabbix的监控方式,还是存在很多亮点,在监控和定制功能上确实很强大,gc功能本身就很强大,但是扩展相对还是比较困难的。 首先我们来show一个概览图,这个是我们努力的目标。比如我们有几十台DB服务器,在开始工作前
主程序 .orig x3000 ld r6,stack ld r0,inter sti r0,vector ld r0,enable sti r0,kbsr again lea r0 ,r6,#-1 str r0,r6,#0 add r6,r6,#-1 str r1,r6,#0 add r6,r6,#-1 str r2,r2,#0 return ldi r0,kbsr ld r1,count show ldi r2,dsr brzp show sti r0,ddr add r1,r1,#-1 brp show br return tail ldr r2,r6 ,#0 add r6,r6,#1 ldr r1,r6,#0 add r6,r6,#1 ldr r0,r6,#0 add r6,r6,#1 rti kbsr .fill xfe00 kbdr 2、中断服务程序 R6是栈指针x4000。 R0存储KBSR的值,用于判断能否读取KBDR的内容。
最近处理一个问题的时候,先是收到DB time升高的报警,然后查看DB time的情况发现,已经有近1000%的负载了。 带着好奇心想看看到底是什么样的一个语句导致如此的情况。 先抓取了一个awr
最近处理一个遗留问题,感觉手动修复真是让人抓狂,所以花了点力气写了一个半自动的脚本,总算从这个繁琐的工作中解放出来了。 问题的背景如下图所示。 存在一个很大的统计库(有容灾备库),还有一个历史统计库,