Result Cache result cache是用来存储查询sql得到的结果,给之后的重复查询来使用。通过缓存这些结果,oracle能避免那些重复的实际消耗,并且节省了大量的数据库操作,比如排序、合并、物理io和表关联等。result cache是内存里的一块单独区域,要么是SGA里或者客户端应用程序内存里。存放在里面的缓存结果在不同的sql语句或者不同的会话之间是可以共享的,除非缓存结果本身失效了。结果缓存对于应用程 2020-08-27 Oracle #result cache
oracle中只读用户锁表 由于数据查询的需求,我们常常需要在数据库当中建立只读用户,并且都是赋予的select any table权限。但是有没有想过只读权限的用户也能锁表?并且是以排他锁的形式? 这样就意味着很多‘只读‘权限的用户并不是真正意义上的只读,这很有可能会由于人为失误或者故意的某些行为导致生产环境的严重灾难,先通过几个例子来重现这种现象。 123456789101112131415161718SQL> c 2020-08-24 Oracle
Oracle查看parameter 别人问你数据库的某个参数是多少时,一般我们都是会直接通过show parameter,或者select value from v$parameter的方式,但是这种查询只是查到的当前会话里的参数值,而如果这个会话对参数进行过修改的情况下,查出来的值与数据库实际的值其实是不一样的。 通过字典可以查到好多带有parameter的系统视图,比如V$PARAMETER,V$SPPARAMETER,V$SY 2020-08-17 Oracle
Automatic Memory Management简析 从11g开始引入了AMM(Automatic Memory Management)的概念,AMM管理了SGA+PGA的内存分配,它允许将内存在SGA和PGAs之间进行转移,你只需要指定MEMORY_TARGET一个参数即可,剩下的事情全部交给oracle自己来做。 这里首先解释几个名词: System global area (SGA) SGA是一组共享内存结构,作为SGA组件,包含了一个ora 2020-08-12 Oracle #internal
Zabbix Logrt Monitoring Windows Logs 有些应用程序会每天生成一个当天日期命名的日志文件,对应日志文件里面出现的报错信息要进行实时监控,实际的过程中遇到了很多坑,总结记录下来,供以后参考。 监控设备是多台win机器,而每个win机器上有多个路径不一的日志目录,目录都含有中文。每个目录下每天都会生成一个新的日期命名的log文件,而目前所要做的是对每个日志文件中的多个关键字进行监控告警。 有几个需要思考的地方: 多个机器多个目录肯定是需要 2020-07-28 Zabbix
Zabbix监控GBK字符集的oracle 监控oracle有很多方式,目前主要使用的是通过第三方软件orabbix,它是通过jdbc连到各个oracle数据库上去执行sql,效率还可以,只是目前有个新需求,有个业务监控返回结果必须含有中文,而orabbix中无法配置字符集 ,导致存放到zabbix中时就会乱码,所以只能换一种方式,采用自带的database monitor来监控。整个配置过程很简单,主要是记录下字符集的转换配置。 Linu 2020-07-27 Zabbix #zabbix
ssh登录非常慢 通过ssh登陆一台linux主机非常慢,基本上每次都在10s以上 12345[root@localhost ~]# time ssh 192.168.146.104real 0m13.730suser 0m0.014ssys 0m0.009s 通过ssh -vvv查看建立链接的过程中详细日志,找出最慢的地方出现在哪里 [root@localhost ~]# ssh -vvv 192.168.1 2020-07-22 Linux #ssh
Zabbix监控ogg延迟情况 起因最近ogg出现了一点问题,没有及时发现,于是考虑将ogg的监控也纳入zabbix当中来。对于这一类监控,考虑的地方不单单在于如何监控,而是善用zabbix的模板、自动发现等功能来实现,这样会方便配置以及后期的可扩展性。 获取OGG信息首先对ogg的运行情况查看通常是通过info all命令 1234567891011121314151617181920MANAGER RUNNING 2020-07-09 Zabbix #ogg #zabbix
ORA-00445: background process W003 did not start after 120 seconds 一个11g的数据库出现报错,根据字面判断可能是某个slave进程启动失败。这种ORA-00455错误通常表示在操作系统层面为了响应某种请求而去生成一个新的进程时因为某种原因导致失败,最有可能的原因一般是由于操作系统资源不足或者配置错误,所以这个错误的解决途径通常是从操作系统层面入手,但是也有部分情况是与oracle有关的。 这里显示的120s超时可以通过设置event事件来进行动态修改 1234$ 2020-07-02 Oracle #ora-
不同版本之间的EXPDP/IMPDP 故障现象将一个18c版本的dmp导入到11.2.0.4当中时出现报错 12ORA-39000: bad dump file specificationORA-39142: incompatible version number 5.1 in dump file "/u01/schema_dump.dmp" 这是由于高版本导出的dmp文件在低版本数据库当中无法识别。 解决办法: 2020-04-09 Oracle #datapump #ora-