ITPub博客

通过配置，可以把/var/log/messages中的日志记录到远程的机器，这样当这个主机被黑掉，SYSLOG也被抹掉之后，也可以在远程保留一份系统LOG的记录，然后可以事后来查系统操作的一些记录。所以我们通过对/var/log/secure中的记录进行判断，然后及时的发邮件出来，通知大家有人登录到某台主机了。这套机制一直运行很好，不过唯一的毛病就是每次登陆，都会出现两条重复的记录，每次登陆发两封邮件，很烦人，下面来看看这个BUG。[@more@]日志中记录的这两条记录之间相差正好8个小时，很容易就想到可能是时区的问题，因为我们正好和标准时间相差8

昨天在pub问了个行列转换的问题，有大侠提出了解决办法，拷贝作来，做个记录吧。实现了把其中两列分别与其他列进行组合，然后把一行数据转化成两行，转换后的数据量是现在的两倍。[@more@]SQL> select empno, ename, job from emp where deptno = 10; EMPNO ENAME JOB---------- ---------- --------- 7782 CLARK MANAGER 7839 KING PRESIDENT 7934 MILLER CLERKSQL> select b.empno, decode(a.rn,1,b.ename,b.job) info from 2 (select rownum rn from dual connect by rownum <= 2)

这不是什么鬼片，而是发生在机房的一次事故。因为扩容需要，去机房添加一个盘柜，然后把这些空间添加到主机，因为主机不能动态识别这些新添加的空间，所以重启主机。主机上跑的业务不能停机很久，于是重启命令敲完，准备接个显示器上去看看启动的过程，万一需要按个F1或者碰见什么故障暂停了，也好及时处理。没想到惊险一刻很快就来了。[@more@]显示器电源往拖线板上一插，啪啪的冒了几下火星，吓了一跳，这倒没啥，小时候刚学会玩电器的时候，被电、冒火星甚至电线烧掉都发生过，这点小故障吓不到我的。不过恐怖的是马上收到短信报警，打

一个逻辑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

因为清理历史数据需要，所以对一列老的RANGE分区直接做DROP操作，因为这些分区表上还有GLOBAL索引，而业务又不能停，所以DROP的时候使用了UPDATE GLOBAL INDEX参数，使得DROP分区的时候索引不会失效。在处理最大的一个1.7亿的表（每个分区大概有4千万数据）的时候，DROP第一个分区，没问题，清除第二个分区过程中，收到系统监控的报警：Errors in file /u01/app/oracle/admin/billdb/bdump/billdb1_lns1_28689.trc:ORA-00272: error writing archive logThu May 8 22:23:26 2008LGWR: I/O error 272 archiving log 2 to 'dgp'DGP是PHYSIC

前段时间写过一个很丑陋的过程来做这个事情，后来发现使用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

生产系统上的STATSPACK是15分钟一次的，但是一天这么多次都发邮件出来也没很大必要，因此每天凌晨把前一整天的报告发出来，有时候发现了TOP 5的等待事件中出现了以前没出现过的异常，也不大好找这个等待集中发生在哪里。因此，先从事务量下手，写个脚本来统计哪个时间段内的事务量最大，当然，这应该是个系列，回头碰见问题了再慢慢写其他统计量最大的脚本。[@more@]其实这些脚本都可以从statspack的spreport的脚本中稍微整理得到，记录在次以方便以后使用：DECLARE --可以找到输出的事务量最大的对应的那个statspack的endid，然后 --在

系统出现ORA-00600错误，看看了TRACE文件，发现是一个插入的SQL语句导致的，看看这个SQL没有任何异常，而且第一次碰见这样的问题，这种问题基本只有METALINK能够解决，到METALINK上搜索了一把，发现有三个相关的BUG。第一个说：corrupt index creating functional index from existing local index；第二个说：when creating index on table containing a NULL REF column；第三个说：ALTER TABLE MOVE corrupts an IOT (OERI:6302 or silent corruption)。三个都是DDL操作出现的问题，都跟我们的情况不一致，导致问题的这个SQL相关的表不

系统中有时候会出现如下警告信息： bt1 kernel: warning: many lost ticks.bt1 kernel: Your time source seems to be instable or some driver is hogging interuptsbt1 kernel: rip __do_softirq+0x4d/0xd0bt1 kernel: Falling back to HPET下面简单记录一下搜索出来的相关内容[@more@]在某些系统上，当首次访问一些 IDE 设备时，可能显示信息warning:many lost ticks（警告：丢失许多嘀嗒信号）。当 IDE 设备没有使用 DMA 进行数据传输时，会显示此信息，因为非 DMA 传输所用的时间比计时器嘀嗒信号间隔长很多（在此期间，处理器

最近和bug干上了，每过十天半个月总会碰上一两个bug，郁闷。今天碰到的是DELETE或者TRUNCATE表时速度很慢的bug。[@more@]因为需要对一些无用的表空间进行清理，腾出系统空间，表空间大概有100G。首先想到的是把几个10多G的大表先truncate，然后再drop所有的表，最后再删除表空间。可是TRUNCATE一个表慢的要死，干脆cancel了，然后直接drop这个表，这次倒很快，可是想想，表肯定放在了recyclebin中了，一看，果然在那里，那就接着purge recyclebin吧，结果等了半个小时，还不见结果，慢的要死，看着表空间已使用空间一分钟才减少了100M，这

生产系统上了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-------------- -

SCP是使用SSH协议进行主机之间数据传输的常用命令，但有时候如果主机不在同一个机房，那么这个数据拷贝占用的带宽就是要好好考虑的问题了，SCP提 供了-l参数来限制带宽的占用，但限制带宽的同时却增加了拷贝需要的时间。一个比较好的办法就是在主机端先进行数据压缩，然后SCP过去后再解压。好在 SSH和SCP已经为我们准备好了这些解决问题的办法。[@more@]默认情况下的SSH是不支持压缩的数据传输的（不同版本的默认值可能不一样，可以通过man sshd_config来查找文档进行确认），要支持压缩的数据传输，那么首先要修改SSH的配置文件（一般位

数据库是运行在操作系统上的，而且和操作系统紧密结合，因此有时候对数据库的优化不得不深入到操作系统层面。 在查找别的资料的时候看见了eygle曾经写过AIX上通过调整LGWR进程的优先级来解决大事务量系统的性能问题，于是看了点linux下进程优先级相关的概念。 [@more@]linux下的进程调度优先级是从-20到19，一共40个级别，数字越大，表示进程的优先级越低。默认时候，进程的优先级是0。查看进程优先级有两个办法：ps和top。top命令显示的NI列的值。或者可以使用ps -efl来查看，也是在ni列表示了进程的优先级。进程的优先级可以

准备创建一个逻辑的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

REDHAT LINUX AS4U4上运行的3个节点的ORACLE 10.2.0.2系统，因为前台应用的原因，会导致某些事务一直不提交也不回滚，所以这个事务影响的记录就会出于加锁状态，从而导致后来的事务需要操作相同记录的就会出现一个锁等待事件，为了确定是哪个SESSION BLOCK其他事务，于是根据锁等待时间最长的SESSION的SID去V$SESSION视图中查找BLOCKING_SESSION的值，得到是谁BLOCK了这个SESSION，以便找到问题的根源，然后奇怪的问题发生了，找到的这个BLOCKING_SESSION的值去V$LOCK中查找，却发现这个session根本没有LOCK任何资源，而且，把这个SESSION