<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[killvoon的专栏]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/killvoon</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; killvoon]]></copyright><item><title><![CDATA[达梦数据守护搭建]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/144667361</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/144667361</guid><author>killvoon</author><pubDate>Mon, 23 Dec 2024 15:02:21 +0800</pubDate><description><![CDATA[达梦数据守护搭建]]></description><category></category></item><item><title><![CDATA[奇怪的ora-12081:update operation not allowed on tablexx.xx]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/119997568</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/119997568</guid><author>killvoon</author><pubDate>Mon, 30 Aug 2021 15:25:44 +0800</pubDate><description><![CDATA[生产环境有套oracle10.2.0.4的库迁移到12.2.0.1版本，采用expdp/impdp方式，这样的操作这几年其实做了挺多次的。

早上开发跟我说有张表不能dml操作，报错ora-12081:update operation not allowed on table xx.xxx

oracle在11g版本支持了将表改为只读状态即alter table table_name read only;

但生产环境倒是头一次遇到，而且是expdp/impdp的情况下。

先将表改为读写：alter ta]]></description><category></category></item><item><title><![CDATA[expdp遇到StreamsAQ: enqueue blocked on low memory]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/114961878</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/114961878</guid><author>killvoon</author><pubDate>Thu, 18 Mar 2021 09:01:09 +0800</pubDate><description><![CDATA[有套oracle12.2.0.1环境，expdp备份一直很正常，但突然有一天备份的特别慢，由于数据库有1个多T，导致24小时都备份不完，但之前大概需要5个小时左右。

监控的时候发现备份进程一直在等待StreamsAQ: enqueue blocked on low memory，印象中以前也遇到过，增加了large pool的大小后即可，但这次不好使了。

查了下相关资料，有种情况是sga设置成自动调整，expdp备份的过程中需要调整stream pool大小，但没有调整成功，就会一直卡在该等待事件上:
]]></description><category></category></item><item><title><![CDATA[ORA-04031: unable to allocate 13840 bytes of shared memory (“shared pool“,“unknown object“,“sga heap]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/114088183</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/114088183</guid><author>killvoon</author><pubDate>Thu, 25 Feb 2021 16:21:00 +0800</pubDate><description><![CDATA[还是年前的时候，绩效系统一直告警，查看了下，库上一直报ora-4031，很常见的错误，当时下意识的认为是内存不足了。

应该绩效手上在exadata一体机上，该一体机上还装了其他几套系统，内存资源比较紧张。

当时flush了下shared_pool，但没啥效果，因为是rac环境，便依次重启了实例，故障就消失了。

没过多久，绩效数据库又出现了这样的情况，共享池不足，就感觉不对劲了，但当时是年底了，马上就过年了，没啥心思探究。

结果过年期间，同属于exadata上crm系统也出现这样的情况，基本确定确实有]]></description><category></category></item><item><title><![CDATA[ORA-12542: TNS:address already in use]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/110387973</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/110387973</guid><author>killvoon</author><pubDate>Mon, 30 Nov 2020 14:47:59 +0800</pubDate><description><![CDATA[用python写了个oracle和dataguard环境日常巡检的程序，跑了有几年了，上周六晚上突然爆出这样的错误。

恰巧当晚有停机维护，以为是网络那边动了东西导致的，后来查了点相关信息。感觉不是网络问题，还是我这边程序出问题。

程序是将根据ip列表依次巡检各个数据库，然后将巡检信息写入到我的一个oracle里面，我以为是由于现在巡检的数据库太多，并发量大，导致这台oracle服务器无法分配更多的tcp端口来处理。折腾了半天，还是没有解决问题。

查了些资料，应该是我程序所在的windows2003服务]]></description><category></category></item><item><title><![CDATA[expdp导出报ORA-06580: Hash Join ran out of memory]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/108200668</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/108200668</guid><author>killvoon</author><pubDate>Mon, 24 Aug 2020 15:45:36 +0800</pubDate><description><![CDATA[一套测试环境使用expdp导出数据，报出ORA-06580: Hash Join ran out of memory的错误，这个是倒是第一次遇到，随手记录一下。

看到这个错误第一反应就是哪块内存区设置的小了，导致expdp操作的时候内存不足。查询了下，MOS上有相关文档，可能是由于

pga_aggregate_target=0

workarea_size_policy=MANUAL

这俩参数设置成如上值导致的。

看了下环境参数，pga_aggregate_target倒是设置了具体的值，但work]]></description><category></category></item><item><title><![CDATA[第一次遇到在awr top 5 event中出现enq:SS-contention 和enq:TS-contention]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/107838238</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/107838238</guid><author>killvoon</author><pubDate>Thu, 06 Aug 2020 14:30:19 +0800</pubDate><description><![CDATA[开发人员跟我说有台测试环境数据库有问题，很卡，应用程序启动起来就卡住，根本无法使用。但没有报任何ora-相关的错误，让我瞧瞧T

我用plsql developer登录下，发现还好，看了下最近的alert日志，也没有异常。下意识的觉得不应该是数据库问题，可能是开发那边网络之类导致出现卡顿的情况。恰巧到饭点，无心恋战，开发人员就让我将数据库重启下，我内心不深处觉得重启是解决不了问题的，但开发给我的回复是重启后好了。

心里一直挂着这事，午休后上班就再次登录上去仔细查验一番。首先看了下最近几天awr DB Ti]]></description><category></category></item><item><title><![CDATA[TNS-12535 TNS-12606 When Sending Security Logging to the Database]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/107150527</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/107150527</guid><author>killvoon</author><pubDate>Mon, 06 Jul 2020 11:06:26 +0800</pubDate><description><![CDATA[有套数据库环境一直报警无法连接，但立马又报警恢复正常，查看了下alert日志，大量如下信息：

Fatal NI connect error 12170.

 VERSION INFORMATION:
TNS for Linux: Version 12.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 12.2.0.1.0 - Production
TCP/IP NT Protocol Adapter f.]]></description><category></category></item><item><title><![CDATA[mysql之全局缓存和线程缓存]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/104472830</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/104472830</guid><author>killvoon</author><pubDate>Mon, 24 Feb 2020 11:05:43 +0800</pubDate><description><![CDATA[全局缓存：

key_buffer_size：决定索引处理的速度，尤其是索引读的速度。默认值是16M。该参数只对MyISAM表起作用。

innodb_buffer_pool_size: InnoDB使用该参数指定大小的内存来缓冲数据和索引，这个是Innodb引擎中影响性能最大的参数。

innodb_additional_mem_pool_size: 指定InnoDB用来存储数据字典和其他内部数...]]></description><category></category></item><item><title><![CDATA[mysql之mysqldump工具参数学习]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/104388251</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/104388251</guid><author>killvoon</author><pubDate>Wed, 19 Feb 2020 10:59:48 +0800</pubDate><description><![CDATA[去年就想把mysql ocp考一下的，但一直没有耐住性子去做题，又总是走马观花式的看些学习资料，总感觉无所得。今年受疫情影响，空闲时间较多，惟愿静下心来，脚踏实地如当初学习oracle一般，从基础知识开始，一点一点积累。

现在的策略是，根据mysql ocp题库，以题目所涉及的知识点入手，以点到面的方式来填充mysql知识图谱。

--------------------------------...]]></description><category></category></item><item><title><![CDATA[weblogic控制台报错:已禁用所需的Mbean服务器，这将阻止weblogic管理控制台的正常操作]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/104062690</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/104062690</guid><author>killvoon</author><pubDate>Tue, 21 Jan 2020 15:58:21 +0800</pubDate><description><![CDATA[有套应用环境，weblogic控制台端口号是7010，浏览器登录后报错：

已禁用所需的Mbean服务器，这将阻止weblogic管理控制台的正常操作

请在该域的配置中启用DomainRuntimeMBean服务器和Edit MBean服务器

由于自身对weblogic也不熟悉，看报错的意思，下意识觉得是不是哪个地方禁用了这个什么MBean，鼓弄了半天也没搞定。

通常weblogic控制台都...]]></description><category></category></item><item><title><![CDATA[oracle12c上一个相当实用的特性-move a datafile online]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/104037363</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/104037363</guid><author>killvoon</author><pubDate>Sun, 19 Jan 2020 10:35:59 +0800</pubDate><description><![CDATA[在12c之前的版本迁移数据文件，要么要把表空间offline，要么就是把数据库重启到mount层面来处理，还是比较麻烦的。

最近exadata上面的一个数据磁盘组满了，一直在腾挪空间，小一点的表空间就直接导入导出的方式处理了，几个T的表空间处理起来就比较耗时，业务空窗期没那么长。

一直没有试过move datafile online的方式，今天拿了几个小表空间测了下，命令很简单：

alter...]]></description><category></category></item><item><title><![CDATA[sqlplus / as sysdba ORA-01017:invalid username/password;login denied]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/103202990</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/103202990</guid><author>killvoon</author><pubDate>Fri, 22 Nov 2019 16:25:10 +0800</pubDate><description><![CDATA[一套测试环境sqlplus / as sysdba 一直报ora-01017

以前好像也遇到过，记不清了，折腾了好久，一开始以为是sqlnet.ora文件配置有误，后来又觉得是/etc/hosts配置不对，最后一直纠结于是不是环境变量不对。。。long long time

最后，发现是由于oracle用户属组有误，少了个dba属组

-------------

许久没更新了，很多时候也觉得没...]]></description><category></category></item><item><title><![CDATA[oracle bigfile tablespace的一个缺点]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/97923197</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/97923197</guid><author>killvoon</author><pubDate>Wed, 31 Jul 2019 15:57:28 +0800</pubDate><description><![CDATA[有套生产系统由于数据量比较大，当时图方便直接建成了bigfile tablespace，用起来也没啥不同，只是在RMAN备份的时候发现无法多进程来备份该表空间，导致备份时间稍长，虽觉不爽，但咬咬牙也就忍了。

但是，有天早上上班，发现表空间使用率有点高，于是resize扩了下，结果发现，库上有一堆的会话被阻塞。心慌慌。幸亏resize值不大，几秒钟过去。在我理解中，数据库在线resize数据文件理...]]></description><category></category></item><item><title><![CDATA[oracle被pmon kill掉，一大早的乌龙，提提神]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/92582473</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/92582473</guid><author>killvoon</author><pubDate>Mon, 17 Jun 2019 14:25:06 +0800</pubDate><description><![CDATA[周一的早晨睡意浓郁，伴着略微燥热的天气，心情没有那么舒畅。办公室里的装修味道攒了周末两天依旧扑鼻，人工净化器们陆续登场，也是个个睡眼惺忪。但一闻到办公室里不明气体后，精神抖擞，颇有战苍天斗帝皇之势。

  照例巡检，点开nbu备份监控web界面，刷刷的红了一大片，what's wrong？

  还好还好，报错的都是同一套库，看看信息，原来是D老头的系统。登上服务器看下，O...]]></description><category></category></item><item><title><![CDATA[系统稳定性测试过程中cpu使用率呈缓慢上升趋势]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/91385708</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/91385708</guid><author>killvoon</author><pubDate>Mon, 10 Jun 2019 17:25:12 +0800</pubDate><description><![CDATA[还是许久之前，开发让我帮忙看下他们做性能压测时候的awr报告，说是在做稳定性测试时候发现，随着时间的推移，cpu使用率会越来越高。

我当时取了两个小时的awr，通看了一下，觉得数据库各方面运行的挺好，而且sql语句也没有超过10ms的，应该是比较理想的系统。后来又取了连续10个小时的awr，分析出来结果也差不多。

于是怀疑是不是虚拟机有问题，因为我们测试环境的机器都是虚拟机，怀疑是不是虚拟机或...]]></description><category></category></item><item><title><![CDATA[ORA-56935: existing datapump jobs are using a different version of time zone data file]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/88843784</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/88843784</guid><author>killvoon</author><pubDate>Wed, 27 Mar 2019 14:31:19 +0800</pubDate><description><![CDATA[在做几个环境的数据整合，分别有oracle11g和12.1的库导入到12.2.0.1环境，发现导入的时候报错如下：

ORA-39097: Data Pump job encountered unexpected error -56935
ORA-39065: unexpected master process exception in DISPATCH
ORA-56935: existing d...]]></description><category></category></item><item><title><![CDATA[SUSE12SP2环境安装oracle 11.2.0.4，有点坑]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/88554480</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/88554480</guid><author>killvoon</author><pubDate>Thu, 14 Mar 2019 16:08:20 +0800</pubDate><description><![CDATA[开发测试环境要做一套11g环境，现有的模板中没有，于是从其他环境tar了一个oracle11.2.0.4环境，结果在dbca创建实例的过程中，一直报错，ORA-12547:TNS:lost contact

一开始以为是tar过来的环境解压后没有进行relink all操作，试了几次，发现没用。然后又排查了下/etc/hosts文件，看看是否存在配置错误，一切正常。于是回头看了下relink的日志...]]></description><category></category></item><item><title><![CDATA[expdp遇到ora-00959:tablespace 'TEMP01' does not exist]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/88554146</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/88554146</guid><author>killvoon</author><pubDate>Thu, 14 Mar 2019 15:41:04 +0800</pubDate><description><![CDATA[今天一直在梳理各个环境的expdp备份，发现有套数据库expdp备份一直失败，查看报错信息如下：

ora-00959:tablespace 'TEMP01' does not exist

觉得挺奇怪的，之前只是在impdp操作遇到过表空间不存在的报错，expdp倒是第一次遇到。立马查看了dba_tablespaces和v$tablespace视图，发现并未有TEMP01的信息。

查了dba_...]]></description><category></category></item><item><title><![CDATA[dataguard 备库参数standby_file_management 设置成manual导致数据文件未同步]]></title><link>https://blog.youkuaiyun.com/killvoon/article/details/86672246</link><guid>https://blog.youkuaiyun.com/killvoon/article/details/86672246</guid><author>killvoon</author><pubDate>Mon, 28 Jan 2019 09:38:59 +0800</pubDate><description><![CDATA[早上监控报警，有一套dataguard环境主备库延时几十万秒，查看备库alert日志发现有个数据文件创建不成功，导致备库上的恢复进程失败。

排查发现，参数standby_file_management 的值被设置成了manual，可能是搭建环境的时候粗心导致。

解决方法：

1、select name from v$datafile;

看到这样的文件：

'/u01/app/oracle/p...]]></description><category></category></item></channel></rss>