对于Orabbix监控Oracle来说,它是提供了一个相对轻量级的客户端来综合监控多个数据库实例。从这一点来看,它的角色有点类似于工作中使用的SQLDeveloper或者toad这类的工具。 在之前的章节中,先花了些篇幅去比较zabbix和grid control,其实从功能上来看,基于zabbix的Orabbix的监控功能要有限的多。提供的默认模板中,监控触发器不到20个。 自己梳理了一下,默认的监控触发器在15个左右。 故障类型报警对应项错误类型报错简述数据库没有数据响应Oracle:aliveHigh
这个专题讲解Python相关方面的内容,首先是运维方面,例如数据库,Linux等,后续会有Web,爬虫等。
ORACLE数据库系统是美国ORACLE公司(甲骨文)提供的以分布式数据库为核心的一组软件产品,是目前最流行的客户/服务器(CLIENT/SERVER)或B/S体系结构的数据库之一。Oracle旗下的Oracle数据库监控软件是企事业单位中最重要的监控需要,通过对Oracle数据库的监控,可以全面了解Oracle的运行状态、数据库响应情况、数据库表空用度情况,从而方便Oracle数据库性能优化。
我们在日常Oracle维护中,可能某个SQL语句很慢,有大量的排序操作,这时需要确认下临时文件的使用情况,今天就讲如何直观的在前端显示该结果
Oracle数据库的表空间管理可以说是非常简单和基础的一项维护工作,但是越简单的事情就越要制定统一的规范,这样数据库的各项管理工作才会愈加的简单高效。
近期,在运维的数据库中有一套 11g 和 一套 19c 的环境,使用如下 SQL 查看表空间使用率时竟然需要 1~2 分钟才可以查看结果,两套数据库数据库也就百 GB 级别,为何会这么慢呢?
就在前几天,又有一个客户向我咨询undo表空间使用率的问题。 这让我想起几年前曾经有个省份的案例,客户的实际运维人员是一位刚毕业不久的女孩,几乎不懂Oracle原理,项目经理交给她的任务也是基础运维工作,比如其中一项就是监测数据库各个表空间的使用率,并对使用率超过95%的表空间进行扩展,他们的Oracle版本是10gR2。 由于该客户业务是运营商话单相关的,业务数据量很大(几十T的规模),所以预留存储的空间也很充足。 有一次该客户有其他问题找到我远程处理的时候,我惊奇的发现他们的undo表空间居然有2个多T大小。进而询问运维人员是怎么回事,想必结果大家已经猜到了,这女孩说她日常巡检经常发现undo表空间使用率超过95%,所以她就不停地扩展,直到如今已经加到2个多T规模的大小。她甚至认为undo表空间也是某一个业务的表空间,这就尴尬了。 那么,究竟什么是undo?undo都有哪些实际作用呢?Oracle 10g的官方文档是这样描述的:
ORA-01144: File size (26214400 blocks) exceeds maximum of 4194303 blocks
大家有没这种感觉,不论甲方还是乙方,拿到一套数据库我们很难快速的知道他的配置,数据库状态以及性能状态
本MongoDB模板采集数据,通过mongo命令,执行内置的函数获取监控数据,修复了不支持认证的问题。
版本:Oracle 11.2.0.4 RAC 问题现象:AWR手工创建快照失败,SYSAUX表空间剩余不足。
这个专题主要是一些日常运维中需要用到的命令,不定期更新~~ 1.查询表空间使用率 select a.tablespace_name,a.bytes/1024/ 1024 "Sum MB",(a.bytes-b.bytes)/1024 /1024 "used MB",b.bytes/ 1024/1024 "free MB",round(((a.bytes-b.bytes)/a.bytes)*100 ,2 ) "percent_used" from (select tablespace_name, sum(
其中讲到了利用查看表空间的使用率,这时我们就可以利用Python监控这个数值,等超过阈值后发送邮件通知我们
近期我们运维的数据库有几台出现了 temp 临时表空间使用率过高告警的问题,发现有些 DBA 竟然选择直接添加数据文件或者直接 resize 30G 来消除告警。这样导致临时文件很大占用很多磁盘空间,没有想到优化管理它,临时表空间过大只有重启实例使用率才会下降,如果没有临时表空间实例重启也会自动创建出来,那么今天抽出点时间来说说临时表空间的管理。
如果开启Retention Guarantee的话,oracle会保证未过期的数据不会被覆盖,但是如果这样的话可能会引起DML操作失败
set pages 999 set linesize 999 SELECT a.tablespace_name "表空间名称", 100-ROUND((NVL(b.bytes_free,0)/a.bytes_alloc)*100,2) "占用率(%)", ROUND(a.bytes_alloc/1024/1024,2) "容量(M)", ROUND(NVL(b.bytes_free,0)/1024/1024,2) "空闲(M)", ROUND((a.bytes_alloc-NVL(b.bytes_free,0))/1024/1024,2) "使用(M)", TO_CHAR(SYSDATE,'yyyy-mm-dd hh24:mi:ss') "采样时间" FROM (SELECT f.tablespace_name, SUM(f.bytes) bytes_alloc, SUM(DECODE(f.autoextensible,'YES',f.maxbytes,'NO',f.bytes)) maxbytes FROM dba_data_files f GROUP BY tablespace_name) a, (SELECT f.tablespace_name, SUM(f.bytes) bytes_free FROM dba_free_space f GROUP BY tablespace_name) b WHERE a.tablespace_name = b.tablespace_name;
作者介绍 邓秋爽 云和恩墨技术专家,擅长于SQL tuning、troubleshooting 系统运行过程中可能遇见各种各样的性能问题,如果仅仅是当前系统的性能问题,我们可以通过查询Oracle的数
在Oracle数据库中,表空间与数据文件之间的关系非常密切,这二者相互依存,也就是说,创建表空间时必须创建数据文件,增加表空间时也必须指定表空间;
发现BMSBAK表空间数据文件有8个,全部为自动扩展,大小由5120M——16384M不等,自动扩展的值由1——16384不等(这两处显得很不专业,数据文件大小和扩展值最好保持一致,不要太随意)。
答: 用这套自动扩容脚本就好(我已多年不Coding,下午写的这套代码比较Low,仅抛砖引玉,各位大神可在此基础上改写以便更好地适应自己的DB环境)
那么问题来了,这些都可以解决吗?当然,我写这篇就是为了介绍如何优化SQL*Plus命令行嘛!
收到zabbix告警信息,表空间 SYSAUX 使用率>95%%,系统表空间sysaux使用率超过了95%。
经常使用 Oracle 数据库的朋友,应该对 sqlplus 这个命令行工具不会陌生。基本上每天工作都离不开它,但是这个工具有些不太好用:
前面介绍了如何利用Python搭建一个网站并且介绍了如何在其中执行Oracle命令并在前端显示出来
由于业务增长,频繁的备份还原对于磁盘空间有了更大的空间需求,基本每周500G的磁盘,空间使用率都会达到85%以上,故编写Oracle清理脚本结合crond自动清理Oracle归档日志。
在20171228交易日收市结束后,对2017年历史库hisdb中归档到historysettlement这个schema的增备数据进行了例行检查,经过与生产库DB1的数据比对,发现20170511这个交易日的增量备份数据丢失了。
临时表空间是Oracle数据库的重要组成部分,尤其是对于大型的频繁操作,如创建索引、排序等等都需要在临时表空间完成来减少内存的开销。当然对于查询性能要求较高的操作应尽可能的避免在磁盘上完成这些操作。
公司一套11g的RAC undo表空间使用率在99%,一直不会下降,由于我们用的是自动UNDO空间管理,可能的原因可能就是由于会话一直在利用UNDO里面的内容
USERS表空间也就是默认用户表空间。 在创建一个用户并没有指定此用户使用表空间时,该用户所有信息都会放入到users表空间中。
都还有很多啊, 但是data表空间使用率很高(超过了95%), 但是还剩几百GB呢. 登录服务器查看日志(tail -100f $ORACLE_BASE/diag/rdbms/ddcw/ddcw/trace/alert*.log)报错大概如下:
近期我们在DBASK小程序新关联了运维之美、高端存储知识、一森咖记、运维咖啡吧等数据领域的公众号,欢迎大家阅读分享。
SELECT a.tablespace_name, ROUND(a.total_size) "total_size(MB)", ROUND(a.total_size) - ROUND(b.free_size,3) "used_size(MB)", ROUND(b.free_size,3) "free_size(MB)", ROUND(b.free_size/total_size*100,2) || '%' free_rate FROM (SELECT tablespace_name,SUM(bytes)/1024/1024 total_size FROM dba_data_files GROUP BY tablespace_name) a, (SELECT tablespace_name,SUM(bytes)/1024/1024 free_size FROM dba_free_space GROUP BY tablespace_name) b WHERE a.tablespace_name = b.tablespace_name;
本文作为常用 SQL 系列的第三篇,本文涉及到的 SQL 及相关命令均是在运维工作中总结整理而成的,对于运维 DBA 来说可提高很大的工作效率,值得收藏下来慢慢看。
以下总结了关于 Oracle 数据库临时表空间的相关 SQL 语句: Oracle 临时表空间创建和添加数据文件: --创建临时表空间 tempdata create temporary tablespace tempdata tempfile '/oradata/orcl/tempdata01.dbf' size 30g autoextend off; --新增临时表空间数据文件 alter tablespace tempdata add tempfile '/oradata/orcl/tempdata0
原文:http://www.enmotech.com/web/detail/1/757/1.html
「引言」 为帮助用户解决何时optimize table的烦恼,CDB开发了InnoDB索引物理空间使用率统计功能。 「第一部分 背景」 InnoDB是一种数据按照行存储的引擎。当记录删除时,InnoDB只进行删除标记,后续再异步回收相应空间。InnoDB页面通常为16K大小,示意图如下: 当标记删除记录较多(>40%),页面物理空间使用率较低时,数据文件将因此膨胀,IO分散,数据访问效率降低。用户为了重新获得较好的数据访问体验和节省存储空间,只能进行耗时的表重建操作(optimize table)。
不知道大家在工作中的表空间管理情况如何,大体会分为两派。以前的公司我们更喜欢直接把空间都分配好,比如500G的容量规划,那就提前准备500G,另外一类是我先给定200G,后续的空间就自动增长,反正容量还是500G。这个其实很大程度上就是个人习惯和公司流程规范的差别了。 为什么这么说呢,因为我在一套环境上收到了一个奇怪的报警。 DBA: IP: xxxx Tablespace: PERFSTAT: 122.5% [Critical!!] 关键就在这
梁敬彬老师的《收获,不止SQL优化》,关于如何缩短SQL调优时间,给出了三个步骤,
编者按:留存一下供自己需要时查找。 【免责声明】本号文章仅代表个人观点,与任何公司无关,仅供参考。 编辑|SQL和数据库技术(ID:SQLplusDB) 临时表空间表空间信息 select * from dba_temp_free_space; 临时表空间的使用量 SELECT d.tablespace_name "Name" , NVL(a.bytes / 1024 / 1024, 0) "Size(MB)", NVL(t.bytes, 0) / 1024 / 1024 "U
前面说了Oracle基本参数,接下来会更新些基本概念。 今天说的是undo空间。 ---- Undo空间作用 回滚事务 恢复数据库 提供一致性读 利用Flashback query 查询过去的数
本文 SQL 均是在运维工作中总结整理而成的,对于运维 DBA 来说可提高很大工作效率,当然如果你全部能够背下来那就牛逼了,如果不能,建议收藏下来慢慢看,每条 SQL 的使用频率都很高,肯定能够帮助到你。
kill session: 执行 alter system kill session ‘761,876’(sid 为 761);
作者 | 兰珊,多年数据库服务经验、主要服务于政府、电网等企。擅长数据库升级、迁移、故障处理。
http://www.enmotech.com/services/service.html(专业数据库服务)
今天碰到了一个dataguard在10gR2的bug,不管怎么样确实是在特定的时间做了特定的操作结果碰到了特定的问题。 这个问题是在10gR2的版本10.2.0.4.0的一个库中出现的,在做巡检的时候发现表空间使用率已经很高了,就准备加一些数据文件把这个问题给修复了,按理说这也是一个常规操作,没有什么可圈圈点点的地方。 但是添加完数据文件之后,过了一会,就收到报警说备库出了点问题,自己还纳闷到底是什么原因导致的,带着疑问使用dgmgrl来查看了一下。 DGMGRL> show configuration;
发现有大量的checkpoint incompleted 和Wait for a undo record等待
领取专属 10元无门槛券
手把手带您无忧上云