ITPub博客

因为业务需要，不得不在生产上更新一个千万级的大表，更新过程中产生了4个G左右的日志后发现此更新会导致其他问题，取消更新，然后更正更新的逻辑后，重新对这千万级的数据进行更新，产生6个多G的日志后，更新完成，但是却造成了其他两个逻辑STANDBY的大量延迟。如何加快这些日志的应用，是一个比较严重的问题。[@more@]1、首先是加快主库的更新操作，那么首先关闭主库对STANDBY的归档，减少主库写STANDBY库日志对主库产生的压力，这需要在更新开始前在主库设置log_archive_dest_state_N参数为DEFER，然后主库切换日志来激活这个新的参数设

很久没有碰过mysql数据库了，今天碰见公司的bugzilla使用的mysql数据库忘记了数据库密码了，本来以为很简单的事情，结果还是费了一点点小功夫，记录一下，免的下次再走弯路。[@more@]虽然对mysql不熟悉，不过以自己的oracle经验来看，肯定有办法能重置一个密码的。随便google下，发现都是相同的解决办法，如下：如果 MySQL 正在运行，首先杀之： killall -TERM mysqld。 启动 MySQL ：bin/safe_mysqld --skip-grant-tables & 就可以不需要密码就进入 MySQL 了。然后就是 >use mysql>update user set password=password("ne

在别人推荐下，系统使用了temporary tablespace group，几天没有看AWR，今天发现系统中如下SQL居然排在了TOP读的首位，而且远远高于正常的TOP SQL的读：select min(bitmapped) from ts$ where dflmaxext =:1 and bitand(flags, 1024) = 1024[@more@]GOOGLE了下，发现有人说这是个bug，登陆到METALINK上查询，发现果然是个bug，描述如下：Applies to:Oracle Server - Enterprise Edition - Version: 10.1 to 10.2This problem can occur on any platform.SymptomsAfter the introduction of temporary tablespace groups following query u

在系统后台的TRACE文件中发现了DRM相关的咚咚，这里转帖下METALINK上关于DRM的定义和解释。DRM基本就是在资源REMASTER的时 候使用的，不过除了定义外，也没找到REMASTER发生的必然条件。ML只说当一个资源被从其他节点frequently进行访问的时候，这个资源的管 理权就会从别的节点移交到这个频繁访问的节点。到底什么是frequently呢，还要继续找找了[@more@]ID:390483.1In this Document Purpose Scope and Application DRM - Dynamic Resource management DRM - Dynamic Resource Mastering ReferencesApplies to:Oracle Ser

有人的地方就有江湖，有资源等待的地方就有死锁。写完主键的死锁，基本上ORACLE的死锁也就都在这里了--主外键死锁、BITMAP索引死锁、ITL死锁，还有最常见的事务锁的引发的死锁。主键的死锁很容易模拟出来的，建一个表，插入一个值，然后不要COMMIT，另一个会话插入另一个值，也不要COMMIT，然后再把这两个插入的值互相交换一下，在两个会话中分别插入，死锁产生。更深入的分析也不想写了，记录一下TRACE文件吧。[@more@]Deadlock graph: ---------Blocker(s)-------- ---------Waiter(s)---------Resource Name

这玩意来自一篇03年的文档，估计很古老了，所以有些法则可能不适用，使用者请先在自己的环境验证parallel_min_servers最小并行进程数，在ORACLE实例启动的时候，将会自动启动这么多的并行进程放到进程池parallel_max_servers最大并行进程数。当需要的并行进程超过parallel_min_servers时，会自动生成新的并行进程来响应请求，但是总的并行进程数受parallel_max_servers限制parallel_min_percent最少进程的百分比。当新的申请超过parallel_max_servers的限制的时候，那么如果池中剩余的进程>申请的进程*parallel_min_percent，则会把池中

先介绍一下标题中的错误是怎么发生的。因为一个BUG，ORACLE提供了一个更新数据字典的解决方案，但是需要更新后ABORT数据库并重启。不能确 定ORACLE提供的方案是否靠谱，ORACLE也推荐先使用现有的备份恢复一个库出来进行测试，我这里也正好有一个物理的DATAGUARD（下面简称 DG），那就准备拿这个物理的DG开刀了。[@more@] 首先介绍下环境：LINUX REDHAT AS4平台上的ORACLE 10.2.0.2，主库单节点，后面拖了一个物理的DG用来做切换，同时也拖了一个逻辑的DG用来做读写分离。先把物理的DG宕下来，然后进行一个冷备，然后把物理DG

一个测试数据库隔三差五的报一个ORA-02019出来，查找alert文件，有一个详细的trace：*** 2007-10-12 21:47:55.083ERROR, tran=2.34.74876, session#=1, ose=0:ORA-02062: distributed recovery received DBID 78d96835, expected 2421f8a5*** 2007-10-12 21:49:08.093ERROR, tran=2.34.74876, session#=1, ose=0:ORA-02019: connection description for remote database not found看来这个ORA-02019只是表面现象，引起的原因应该是ORA-02062[@more@] 网上搜索了下，找到了老和尚的解决办法，记录在此吧：处理办法：(1) set

看TOM的PPT中有一份演示，其实在LEWIS的COST BASED中也有类似的例子，就是说如果我一个字段是时间类型的，那我可以有很多种变通的存储方式。比如2010年12月1日，可以存储成DATE类型； 也可以存储成字符串20100101；也可以存储成NUMBER类型的20100101。这些存储方式也都可以用来做大小比较，查询等等，有些开发人员确 实有把DATE转化成NUMBER存储的习惯。下面就借用TOM的例子来看看相同的数据，采用不同的类型存储的时候，对优化器以及执行计划（查询效率）的 影响。[@more@]首先创建一个表，并插入些测试数据（下面代码摘自TOM

问题提出： 两个表的关联查询，一个表数据量在千万，一个表数据量只有几条（参数表），大表是按时间进行的分区表，而且时间字段上还建有分区索引。刚开始，执行计划是正确的，但是后来却发现两个表的关联不是走分区表的索引，而是直接扫描整个分区，有点费解。[@more@] 了解业务后发现，参数表中有两个字段，一个是起始时间，一个是终止时间，这两个时间间隔一般在10分钟。每过一段时间，将拿参数表中的时间出来，然后根据时间段去大表中查询这段时间内进行的业务。大表每天新增数据在20万左右，10天一个分区，小表数据量不

问题提出：一台测试的服务器，停电再起来后发现listener起不来，报错如下：Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.191.100)(PORT=1521)))Error listening on: (ADDRESS=(PROTOCOL=ipc)(PARTIAL=yes)(QUEUESIZE=1))No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.191.100)(PORT=1521)))TNS-12549: TNSperating system resource quota exceededTNS-12560: TNSrotocol adapter errorTNS-00519: Operating system resource quota exceededLinux Error: 28: No space left on device[

一个逻辑STANDBY库提供些报表业务，不过最近发现这个库的负载有点偏高，而且SQL APPLY也有些缓慢。想着这个库是运行在NAS上的，而且只是一个千兆的网络，如果用户太多或者压力太大，响应缓慢是正常的，但是登陆系统却发现 IOWAIT很小，但CPU资源占用很多，而且奇怪的是占用CPU资源多的还都是P开头的并行进程，并行进程为啥占用这么多CPU呢？[@more@]首先想到的是有表或者索引PARALLEL开的太高，但查询后发现这些进程并不是用户前台进程，而是系统后来SQL APPLY使用的进程，并且等待的都是CACHE BUFFER CHAINS的事件。这个问题以前处

linux平台上的Oracle Clusterware 10.2.0.4和以后版本引入了一个新的Oracle Clusterware Process Monitor Daemon (OPROCD)进程来监控系统状态和集群中的每个节点的健康状态，就象已经在不使用第三方的cluster软件的UNIX系统中提供的那样，下面来看看OPROCD到底是何方神圣。[@more@]OPROCD在linux平台上的10.2.0.4版本中和hangcheck-timer一起运行，它和hangcheck-timer模块没有联系和依赖关系，它由init.ccsd进程产生出来并用root用户运行。OPROCD进程被锁定在内存中来监控集群中的每个它自己运行的节点，来检测机器上的硬件或者驱动的fre

前段时间写过一个很丑陋的过程来做这个事情，后来发现使用lag函数可以轻松实现，其实只要把STATS$SYSSTAT中的数据按照snap_id排序一下，然后用下一个减去上一个，得到的就是事务量了。同理，只要去statspack的spreport中挖掘，相应的哪个时间段产生redo最多，哪个时间段物理读最大等等都可以实现。[@more@]1、哪段时间的每秒事务量最大 SELECT B.SNAP_TIME, A.SNAP_ID, ROUND((SUM(A.VALUE) - LAG(SUM(A.VALUE), 1, SUM(A.VALUE)) OVER(ORDER BY B.SNAP_TIME)) / (B.SNAP_TIME - LAG(B.SNAP_TIME, 1

生产系统上了RAC，几天后接到同事报告，说一个取sequence的地方数据有问题，按数据插入时间来判断先取的sequence值大，而后取的反而小，与之前对sequence的理解有出入。测试如下[@more@]在节点一上：Connected to:Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit ProductionWith the Partitioning, Real Application Clusters and Data Mining optionsSQL> create sequence seq_t2 minvalue 13 maxvalue 9999994 start with 15 increment by 1;Sequence created.SQL> select seq_t.nextval from dual;NEXTVAL--

最近GRID CONTROL热起来了，所以想装一个看看，下载下来，解压，然后在压缩包中找到了一个PDF的安装指南，看了一下，基本跟安装ORACLE差不多，打几个PATCH，然后设置下SYSCTL参数就可以开始了，这台机器本来就曾经装过ORACLE的，所以仔细检查了下缺失的包，打上，然后开始安装。结果最后执行到Web Cache CA的这一步时，死活找不到libdb.so.2库，问题来了。[@more@]首先去磁盘上翻翻到底有没有这个问题，find / -name libdb.so.2，结果在/usr/lib64/找到了这个咚咚，而且是一个链接。仔细看看报错，是找不到/usr/lib/libdb.so.2，GOOGLE了一

比如我想知道我的EMAIL在测试系统中存在了什么位置，那就需要DUMP BLOCK来查看了，可是索引不像数据，数据的话我只要知道ROWID，然后根据ROWID得到数据存在于哪个数据文件的哪个块中，然后直接DUMP这个BLOCK就可以了。可是索引存了ROWID，但是你却SELECT不出来，下面来演示下怎么找到一个值在索引中存在于什么地方[@more@]首先得到索引的OBJECT_ID，然后DUMP出这个索引的根信息：SQL> select DATA_OBJECT_ID,OBJECT_ID from dba_objects where object_name='IDX_MEMBERIDENTITY_IDCONTENT'; DATA_OBJECT_ID OBJECT_ID-------------- -

准备创建一个逻辑的STANDBY数据库供开发的查询生产数据使用，但是把物理的standby转换成逻辑standby的时候，碰到了ORA-16146: standby destination control file enqueue unavailable错误，于是故事开始。。。[@more@]首先建好了物理的standby，然后使用语句alter database recover to logical standby dgl201把物理的standby转换成逻辑的standby，日志如下：Sat Dec 22 09:00:20 2007alter database recover to logical standby dgl201 --这里是开始转换的命令Sat Dec 22 09:00:20 2007Media Recovery Start: Managed Standby Recovery (

很多时候RAC中的节点宕机的时候，因为CPU或者磁盘等资源的繁忙或者其他问题，导致缓冲区中的日志还没有被写入磁盘上的日志中，节点就已经被重启，给故障诊断带来一定的麻烦，通过适当设置DIAGWAIT的值，使得节点被驱逐到真正OS REBOOT之间的时间适当延长，则可以记录更多有帮助的日志信息。具体操作过程如下（摘自METALINK:559365.1）[@more@]1、停止所有节点的CRS #crsctl stop crs 2.停止10.2.0.3到11.1.0.6版本的RAC中才引入的OPROCD进程 #<CRS_HOME>/bin/oprocd stop 3、检查是否还有CRS相关的进程在运行 ps -ef |egr