Waitin'Alone

南美丛林的一只蝴蝶煽动翅膀，可能导致莫斯科下大雪，说明的大气系统的复杂性。而DBA在日常工作中叶经常会面临类似的问题，我们从故障的表象上分析问题处理问题，而往往我们采取的措施仅仅是解决一些表象的问题，并没有找到问题的关键。也就是说，我们并没有抓到扇翅膀的那只蝴蝶，而仅仅抓住了莫斯科上空的乌云。

前几天碰到一个案例，写出来和大家共享。客户有一套系统下午1点多的时候，突然出现了故障，服务无法响应，新会话连不上去。最后只能通过杀掉了大量的会话，才恢复正常。客户想找到问题的原因。找到我的时候已经是下午的4点多了。出现故障的时段有大量这样的信息：

Mon Apr 11 12:52:24 2011

Errors in file /oracle/app/oracle/admin/sjzzw2/udump/sjzzw22_ora_10410.trc:

ORA-00603: ORACLE server session terminated by fatal error

ORA-27544: Failed to map memory region for export

ORA-27300: OS system dependent operation:bind failed with status: 227

ORA-27301: OS failure message: Can't assign requested address

ORA-27302: failure occurred at: sskgxpcre3

Mon Apr 11 12:55:01 2011

Errors in file /oracle/app/oracle/admin/sjzzw2/udump/sjzzw22_ora_13426.trc:

ORA-00603: ORACLE server session terminated by fatal error

ORA-27544: Failed to map memory region for export

ORA-27300: OS system dependent operation:bind failed with status: 227

ORA-27301: OS failure message: Can't assign requested address

ORA-27302: failure occurred at: sskgxpcre3

Mon Apr 11 12:55:25 2011

Errors in file /oracle/app/oracle/admin/sjzzw2/udump/sjzzw22_ora_13934.trc:

ORA-00603: ORACLE server session terminated by fatal error

ORA-27544: Failed to map memory region for export

ORA-27300: OS system dependent operation:bind failed with status: 227

ORA-27301: OS failure message: Can't assign requested address

ORA-27302: failure occurred at: sskgxpcre3

Mon Apr 11 12:55:25 2011

Errors in file /oracle/app/oracle/admin/sjzzw2/udump/sjzzw22_ora_13936.trc:

ORA-00603: ORACLE server session terminated by fatal error

ORA-27504: IPC error creating OSD context

ORA-27300: OS system dependent operation:bind failed with status: 227

ORA-27301: OS failure message: Can't assign requested address

ORA-27302: failure occurred at: sskgxpcre3

Mon Apr 11 12:55:25 2011

Errors in file /oracle/app/oracle/admin/sjzzw2/udump/sjzzw22_ora_13938.trc:

ORA-00603: ORACLE server session terminated by fatal error

ORA-27504: IPC error creating OSD context

ORA-27300: OS system dependent operation:bind failed with status: 227

ORA-27301: OS failure message: Can't assign requested address

ORA-27302: failure occurred at: sskgxpcre3

Mon Apr 11 12:56:00 2011

Thread 2 advanced to log sequence 2945 (LGWR switch)

Current log# 4 seq# 2945 mem# 0: /redolog/sjzzw2/redo04.log

Mon Apr 11 12:56:01 2011

Errors in file /oracle/app/oracle/admin/sjzzw2/udump/sjzzw22_ora_14554.trc:

ORA-00603: ORACLE server session terminated by fatal error

ORA-27544: Failed to map memory region for export

ORA-27300: OS system dependent operation:bind failed with status: 227

同时还存在一些类似的ORA-27XXX错误：

Mon Apr 11 12:56:33 2011

Errors in file /oracle/app/oracle/admin/sjzzw2/udump/sjzzw22_ora_22957.trc:

ORA-27509: IPC error receiving a message

ORA-27300: OS system dependent operation:recvmsg failed with status: 216

ORA-27301: OS failure message: Socket operation on non-socket

ORA-27302: failure occurred at: sskgxprcv1

Mon Apr 11 12:56:33 2011

Errors in file /oracle/app/oracle/admin/sjzzw2/udump/sjzzw22_ora_25431.trc:

ORA-27509: IPC error receiving a message

ORA-27300: OS system dependent operation:recvmsg failed with status: 216

ORA-27301: OS failure message: Socket operation on non-socket

ORA-27302: failure occurred at: sskgxprcv1

Mon Apr 11 12:57:24 2011

根据

ORA-27300: OS system dependent operation:recvmsg failed with status: 216

现场工程师认为是BUG 6689903导致，建议关闭NUMA。客户准备晚上实施关闭NUMA的操作，想听听我的建议。我觉得关闭NUMA时一个十分大的操作，应该十分谨慎，因此先要搞清楚到底是什么导致了今天的问题。从ORA-27300来看，一般来说是某种OS资源不足导致的问题。因此我们首先要从分析错误信息开始，HP-UX的ERRNO=227，216

# define ENOTSOCK 216 /* Socket operation on non-socket */
# define EADDRNOTAVAIL 227 /* Can't assign requested address */

216是在非SOCKET上操作SOCKET操作，227是无法分配地址。对于BUG 6689903，Oracle官方解释是使用了NUMA后，Oracle存在一个BUG，导致一个会话使用了大量的UDP端口，造成UDP端口不足。可以通过打补丁或者关闭NUMA来解决这个问题。而UDP端口耗尽也可能出现ERRNO =227，无法分配地址的错误。因此可以初步判断是由于UDP端口耗尽导致了问题。在这种情况下打PATCH 6689903可以解决过多UDP端口被一个会话消耗的问题，但是不一定能解决所有的问题，当系统负载进一步加大（系统设置的PROCESSES=4500，而出故障时发现会话数无法突破1600）,可能还会出问题。关闭NUMA虽然可以减少UDP端口的使用，但是会降低系统的性能，无法充分享受大型SMP系统的架构优势，也是不足取的。因此较好的解决这个问题是打PATCH 6689903，避免由于BUG过多消耗UDP端口，另外调整UDP端口的范围，从而让OS提供更多的UDP端口。通过下面命令：

我们看到系统的UDP端口使用了缺省值，通过调整这两个值，使中间的区间变大，就能提供更多的UDP端口号了。问题分析道这里，看样子已经解决的差不多了。可能大多数DBA到此就大功告成了。而老白认为其实不然，如果说建议NUMA只是看到了下雪时莫斯科上空的乌云，那么分析到这里也仅仅看到了西伯利亚冷空气的影响。离那只南美洲的蝴蝶还有万里之遥呢。

老白当然会继续分析下去，是什么原因导致了UDP端口号被消耗光呢？客户说平时这个系统会话数在1000出头，故障时会话数达到了1600。这个是UDP端口号被消耗光的一个很好的解释。但是为什么会话数会突增呢?通过对应用架构的了解，我们知道这个系统的大多数应用没有采用连接池，而是客户端直接连接的，当系统处理能力下降时，客户端连接数据库的连接会增加，以适应外部服务的请求。因此我们可以将怀疑点集中到系统出现了变慢的情况。如果在故障前的某个时段，系统突然变慢了，那么就有可能造成会话数增加的可能。会话数增加后，UDP端口配置过低的问题就暴露出来了。

那么接下来我们就需要分析系统为什么会变慢，在什么时间变慢的。我们继续分析ALERT LOG，发现第一次报错的时间是12点41分左右：

王冰玉，就这样被你征服。努力向你看齐。

自信来自内心的淡定与坦然

在今天圣保罗对科林斯蒂安的巴西圣保罗州联赛中，巴西著名门将切尼打进了里程碑式的进球，本场他的任意球破门是其职业生涯的第100球。

在切尼个人官网公布的数据中，对这100个进球进行了详细的分类，其中包括44个点球、55个任意球，另外还有1个运动战进球。作为一个门将，如此“攻击力”实在令人咋舌。

另外，在切尼进球的比赛中，有75场获得了胜利、另外22场平局，失利仅有3场。切尼今年38岁，值得一提的是，从1992年至今，他的整个职业生涯都是在圣保罗一家球队度过的。

问题：有同事反映，新安装的数据库使用 conn sys/oracle@xxxx as sysdba登录不上去，提示ORA-01031: insufficient privileges，而用户名密码都是完全正确的，不使用@xxx连接符conn / as sysdba登录正常。

过程： 首先判断当前系统采用的是操作系统认证，再使用system/manager@xxxx登录时没有问题，只有使用sysdba权限的用户登录才会报这种错误。接下来进行 grant sysdba to scott; 报错，ORA-01994: GRANT failed: password file missing or disabled。注意，问题就在这里，系统提示密码文件问题。查找$ORACLE_HOME/dbs下的orapwSID文件，发现存在。

原因：orapwdorcl不正确，应该为orapwORCL，实例名应大写，安装时输入的实例名为小写造成。

http://wangyu.javaeye.com/blog/304898

HB-BSS-TEST>sqlplus '/as sysdba'

SQL*Plus: Release 10.2.0.4.0 - Production on Wed Aug 11 13:20:04 2010

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

ERROR:
ORA-01031: insufficient privileges

================================

The config.o file may not have been properly generated from the config.s (or config.c) file. There may have been OS user or other changes since the initial install, and hence the ORA-1031 error occurred.

The 'OSDBA' and 'OSOPER' groups are chosen at installation time and usually both default to the group 'dba'.

These groups are compiled into the 'oracle' executable and so are the same for all databases running from a given ORACLE_HOME directory.

Solution

Use the "id" command to see what groups the oracle user belongs to, then check the group in the $ORACLE_HOME/rdbms/lib/config.c (config.s on some OS platforms) to see if they match. If not, then the solution is:

The 'dba' group in the file config.s is set to 'xxx' but your primary group is 'yyy', so to solve the problem, please do the following:

- shutdown all databases running from this home
- cd $ORACLE_HOME/rdbms/lib
- vi config.c

Edit the following lines :

from:

to:

- now remove the existing config.o:

mv config.o config.old

- relink oracle to rebuild config.o and store it inside the oracle executable:

make -f ins_rdbms.mk ioracle

You should now be able to login '/ as sysdba' again.

很多人说，resetlogs就是不完全恢复，这是不对的，做不完全恢复必须使用resetlogs，但resetlogs也可以做完全恢复。而noresetlogs则是必须做完全恢复时使用。resetlogs会重置日志序列号强制清空或重建REDO，而noresetlogs则不会这么做。

第一种情况，我们假设仅仅控制文件丢失，而其他文件没有丢失（主要是归档和REDO），那么恢复的时候如果选择从备份中恢复控制文件。恢复后，控制文件会去读数据文件头中与CHECKPOINT SCN对应的RBA信息来确定从那个序列的归档日志开始恢复，一直推进恢复到NEXT SCN是无穷大的那个REDOLOG，此时恢复是完全恢复的，但打开的时候还要以resetlogs方式打开，这样要重置归档日志的sequence，也就是说，如果你恢复时使用了备份控制文件，那么打开数据库时必然是要resetlogs的。

第二种情况，不完全恢复，不管你是要什么样的不完全恢复，SCN，TIME，跨越REDO，都必须使用resetlogs。

第三种情况，丢失REDOLOG，这就更需要resetlogs了，因为resetlogs能够重建REDOLOG。如果你的REDOLOG、控制文件、数据文件丢失的话，需要先恢复控制文件，然后restore database;recover database;alter database open resetlogs;注意，这时候做的是不完全恢复，因为REDO没有了。在recover过程中可能会报错然后自动退出RMAN，无视，alter database open resetlogs即可，

第四种情况，没有丢失控制文件及各种日志，仅丢失数据文件，这种问题比较常见，有可能磁盘损坏造成数据文件丢失，等磁盘故障排除后，需要恢复，此时的恢复就很简单了，restore database;recover database;alter database open;就一切OK，也就是说，在不使用备份控制文件恢复的情况下，是可以使用noresetlog方式打开数据库的。前提有一，不能丢失日志文件。假若丢失了控制文件和数据文件但还是想以noresetlog打开的话，就必须手动以noresetlogs方式重建控制文件，而且REDOLOG的状态都必须正常，否则是无法使用noresetlogs方式打开。

CONTROL_FILE_RECORD_KEEP_TIME参数 和 retention policy 的关系 1、CONTROL_FILE_RECORD_KEEP_TIME参数 determines how long information that can be used by RMAN is kept in the control file. The default value for this parameter is 7 days and can be as many as 365 days. The greater the number, the larger the control file becomes to store more information. 2、retention policy configure retention policy to recovery window of 30 days; 1: 控制文件中对于 备份相关的信息的保留的时间长度。 2： 备份的过期策略。需要确保有效备份能恢复到 30天之前。 保留时间长度 和 控制文件的大小有一定关系，当然，这个时间也应该大于等于 备份的有效时间长度。

http://haochunpeng.itpub.net/post/385/41016

一日，PL/SQL DEVELOPER工具用sys用户连接数据库报ORA-1031,在本地验证sys密码没错。网上说于passwordfile有关，很多人都关闭数据库后，重建密码文件。

我在10.2.0.1的环境中，直接修改密码文件的名字，v$pwfile_users就能识别了。不晓得他们为什么要停掉库重建passwordfile。

passwordfile在ORACLE_HOME/dbs下，格式为orapwSID。

注意：1.是orapw而不是orapwd

2.是orapwSID而不是orapwSID.ora

sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on Wed Oct 21 00:39:50 2009

Copyright 1982, 2005, Oracle. All rights reserved.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit;
Statement processed.
SQL> oradebug dump systemstate 266
ORA-03113: end-of-file on communication channel
ORA-24323: value not allowed
alert:

ORA-07445: exception encountered: core dump [kgldmp()+1177] [SIGSEGV] [Address not mapped to object] [0x18] [] []

----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+27 call ksedst1() 1 ? 1 ?
ksedmp()+557 call ksedst() 1 ? B7489F84 ? B7489F84 ?
B7489F8C ? FFFFFFFF ?
B7489F84 ?
ssexhd()+863 call ksedmp() 3 ? AE92925 ? 646C676B ?
2928706D ? 3731312B ? 37 ?
kgldmp()+1177 signal 00000000 B ? B748BC90 ? B748BD10 ?
kgllkd()+1112 call kgldmp() CBC2A40 ? 30AD841C ? 3 ? 1 ?
kssdmp1()+206 call 00000000 CBC2A40 ? 2EB37A78 ? 3 ?
kssdmh()+191 call kssdmp1() 2EB37A78 ? 3 ?
ksudms()+834 call kssdmh() 30F12C34 ? 2 ? 30F12C34 ? 2 ?
kssdmp1()+98 call 00000000 30F12C34 ? 2 ?
kssdmh()+191 call kssdmp1() 30F12C34 ? 2 ?
ksudmp_proc()+683 call kssdmh() 30E184B4 ? 1 ? 30E0840C ?
184 ? 1 ?
ksudss()+2815 call ksudmp_proc() 30E184B4 ? 1 ? 0 ?
ksdxfdmp()+1382 call 0C95AEEA A ? BFFFCAEC ? BFFFC664 ?
CB740C0 ? B7FF4F39 ?
BFFFCEF7 ?
ksdxen()+2771 call 00000000 BFFFD8D4 ? 14 ? 3 ?
BFFFCAD0 ? BFFFCB20 ?
opiodr()+2347 call 00000000 56 ? 11 ? BFFFED44 ?
ttcpip()+4227 call 00000000 56 ? 11 ? BFFFED44 ? 0 ?
CC2ABA6 ? 17 ?
opitsk()+1991 call ttcpip() CBCA240 ? 56 ? BFFFED44 ? 0 ?
BFFFE224 ? BFFFEE68 ?
opiino()+1387 call opitsk() 0 ? 0 ?
opiodr()+2347 call 00000000 3C ? 4 ? BFFFF930 ?
opidrv()+915 call opiodr() 3C ? 4 ? BFFFF930 ? 0 ?
sou2o()+113 call opidrv() 3C ? 4 ? BFFFF930 ?
opimai_real()+212 call sou2o() BFFFF914 ? 3C ? 4 ?
BFFFF930 ?
main()+111 call opimai_real() 2 ? BFFFF960 ?
__libc_start_main() call 00000000 2 ?

Bug 4119264 - Dump kgldmp during a SYSTEMSTATE dump

Doc ID: 4119264.8

A dump can occur in kgldmp when taking a library cache or 
system state dump during a time when 'shutdown immediate' is hung.

但是Bug 4119264只在9206下有patch.

QL> alter system flush shared_pool;

System altered.

SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit;
Statement processed.
SQL> oradebug dump systemstate 266
Statement processed.

根据metalink描述,flush shared_pool后问题ok

Question: What is supplemental logging, and how does supplemental logging work?

Answer: When Supplemental Logging is enabled, either some selected columns or all columns are specified for extra logging. They are called a supplemental log group and consist of nothing but a set of additional columns that are being logged. When the supplemental logging is active on a database, the redo logs contain other columns from tables to uniquely identify a row. If the table has a primary key or unique index defined, the only columns involved in the primary key or unique index will be registered in the redo logs along with the actual column(s) that has changed.

If the table does not have any primary keys or unique index defined, Oracle will write all scalar columns from the table to identify the row. This may significantly increase the size of redo logs and will impact the log apply services on the logical standby site.

There are two types of supplemental log groups that determine when columns in the log group are logged:

• Unconditional Supplemental Log Groups - The before-images of specified columns are logged any time a row is updated, regardless of whether the update affected any of the specified columns. This can be referred to as an ALWAYS log group.
  

• Conditional Supplemental Log Groups - The before-images of all specified columns are logged only if at least one of the columns in the log group is updated.

Supplemental Logging can be enabled at database level or at the table level. When it is enabled at database level, there are two types, minimal logging and identification key logging.

Streams supplemental logging places additional column data into the redo log file whenever an UPDATE operation is performed. At the least, minimal database-level supplemental logging must be enabled for any Change Data Capture source database:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Why is supplemental logging needed? When a particular column is updated at the source database table for a set of rows, the values in the column or columns are logged by default. When these values are moved to the destination side, to which rows does Oracle apply them, or how does Oracle identify the rows to be updated? Supplemental logging provides the answers to these questions.

supplemental logging会在redo里多记录PK or unique index的信息

其目的在于使redo log 可用于logical stand DB的恢复

比如说，redo 里记录了一笔update的操作，如果是普通的log,就只记录rowid的信息，足够做recover / roll-forward之类的
但是由于logical stand DB不是根据rowid 来做recover,所以需要在redo里记录PK or unique index的信息来定位操作的data.

当然，用了supplemental logging之后，redolog 肯定会变多的。


supplemental logging的信息可以从v$database里获得

select SUPPLEMENTAL_LOG_DATA_MIN , SUPPLEMENTAL_LOG_DATA_PK ,
SUPPLEMENTAL_LOG_DATA_UI
from v$database

因为在oracle里在做update操作时候，有些信息是不技术redo log，例如主键或唯一键等，这样在根据redolog 来解析数据是时候你就不知道具体那行数据被修改，如果根据rowid 来做key值的，在不同数据库里脱离了块，rowid也就没有任何意义了，所以oracle提供了supplemenetal log，通过配置启动它，oracle会在redo log里技术主键或唯一键的信息。具体修改方法如下：

--停止supplemental log

alter database drop supplemental log data

--默认启动方法不是完全启动，建议使用下面的指定启动的方法

alter database add supplemental log data

--指定具体的启动的项对应v$database 中的supplemental_log_data_pk,supplemental_log_data_ui
alter database add supplemental log data (primary key ,unique index) columns

--检查修改结果

select supplemental_log_data_min,supplemental_log_data_pk,supplemental_log_data_ui
from v$database

手册介绍:

WITH CHECK OPTION Specify WITH CHECK OPTION to indicate that Oracle
Database prohibits any changes to the table or view that would produce rows that are
not included in the subquery. When used in the subquery of a DML statement, you
can specify this clause in a subquery in the FROM clause but not in subquery in the
WHERE clause.

with check option可以这么解释：通过视图进行的修改，必须也能通过该视图看到修改后的结果。比如你insert，那么加的这条记录在刷新视图后必须可以看到；如果修改，修改完的结果也必须能通过该视图看到；如果删除，当然只能删除视图里有显示的记录。

SQL> select * from dept;

DEPT_ID DEPT_NAME
---------- --------------------
1 a
2 b

SQL> create view v_dept as select * from dept where dept_id>1 with check option;

视图已创建。

SQL> insert into v_dept values(1,'a');
insert into v_dept values(1,'a')
*
第 1 行出现错误:
ORA-01402: 视图 WITH CHECK OPTIDN where 子句违规

SQL> insert into v_dept values(2,'a');

已创建 1 行。

SQL> rollback;

回退已完成。

SQL> select * from v_dept;

DEPT_ID DEPT_NAME
---------- --------------------
2 b

SQL> update v_dept set dept_id=1;
update v_dept set dept_id=1
*
第 1 行出现错误:
ORA-01402: 视图 WITH CHECK OPTIDN where 子句违规

SQL> update v_dept set dept_id=3;

已更新 1 行。

SQL> rollback;

回退已完成。

昨天跟一MM约好今天打羽毛球,昨天下了班,我屁颠屁颠的跑去体育馆订了俩小时交了50元定金.然后兴高采烈的去先天下吃了两个日本小鱼丸,一个骨肉相连,一个蘑菇,还有非常难吃的牛排意大利面.刚回到小区门口,客户打电话,出帐时有个库动弹不得了,哎.我这倒霉孩子呤上像砖头一样沉的电脑就奔向战场.不去不知道,一去吓一条.几千万条记录的delete操作中途断了,占用了大量回滚段,奶奶的,一条语句真能搞垮一个库.接着有两个job不能运行,靠,这写job的人不是脑残就是智障,写的相当业余,而且都一个多月了,愣是不知道咋回事.我在心里默默祝他早日进安定医院免得危害社会.等回来就22点半了.本打算洗洗衣服,得儿,啥都崩干了.折腾了一会就12点了,闭上眼愣是睡不着,翻了N个身,还是没睡着,我这是在想什么呢?

废话了半天,倒霉的我和倒霉的今天终于粉墨登场了.

在倒霉的早上5点半,我那个倒霉的手机突然吱吱的响,睁开一只眼一看原来快没电了,靠,本来昨晚睡得就不好,还这么早把我吵醒了.不管了,先给冲上电继续睡.刚闭上那倒霉的眼睛,外面就打了一个巨响的雷,我心里咯噔一下,今天不会下雨吧?拉开窗帘一看,这倒霉的天气阴着脸呢,幸好没下雨,阴就阴吧,不管了,先睡觉.接着刚闭上那倒霉的眼睛没多久,外面噼里啪啦的响,不知道哪位大爷大妈在放鞭炮呢,靠,今天是什么日子呀,真够倒霉的.但是我坚持闭着我那倒霉的眼睛不睁开,不让我睡,我偏偏要睡给你看.终于熬到起床了,先洗洗澡,洗去所有的晦气.刚要洗,短信来了

MM:我这下了好大的雨,我觉得这是一个睡觉的好日子.今天咱们还玩不玩了?

我跑到窗户一看,我这一个雨点也没下呀,都在一个城市,差距杂就这么大涅.我是实在人,人家说的话肯定是毫不怀疑.

我:我这没下雨,咱继续玩吧.

洗完澡没多久,短信又来了

MM:我这的雨真的好大,要不咱改天再玩吧.

咱是实在人,别人不情愿的事咱不会去勉强

我:呵呵,那好吧.天公真的不做美呀.你继续睡觉吧.不过我还是要去(退场地呀).

MM:其实我都到楼下了,看到这么大的雨,真不知道怎么等车?

我心想,难道暗示要我去接她?(此时窗外开始下雨)

我:你等着我,我去接你吧.

我呤上一把伞,就往外冲,可是这倒霉的伞怎么也打不开,我情急之下用力一撑,结果有根辐条刺穿了我的手指,顿时鲜血直流,我这倒霉的手指头.不管了,我撑着这把倒霉的伞就往外跑了,一边跑着,一遍吮吸着指头,一边还要看MM的短信

MM:呀!真的不用了,下这么大雨,你来多麻烦呀,改天咱们再玩吧.

我刚才还想着先去KFC买两个汉堡给她当早餐,再去接她,相信一个英俊 伟岸 体贴的形象顿时占据她的心灵.可惜我这倒霉孩子没机会啦.算了,去退场地吧.此时精神有点恍惚一不小心一脚踩在一块倒霉的砖头上,一股恶水顿时漫过了我的ad,靠,我这心爱的ad就这么被糟蹋了.这倒霉的砖头,倒霉的破水.等跑到小区门口,鞋差不多都湿了,招手上了一辆D,一上车,那倒霉的司机就嘟囔:把伞甩一下,要不车里就能划船了.靠!你奶奶的,废话咋这么多呀,本来我对石家庄人印象就很差,这让我感到更差了.由于我嘴里一直含着流血的指头,我懒得跟他理论.一会到了体育馆,

我:老板,预约的场地能退么?

老板:不能(很斩钉截铁哦)

我:你扣点钱,少退给我点也行呀.

老板:我们这墙上写着规定呢,这哪能随便改呀.你看宪法什么时候随便改过.

靠!你丫的,废话还真多.要不是我势单力薄,我非得把你场子给砸了,把你那墙上的规定塞到你嘴里.算了,我今天够倒霉了,不跟他理论了.然后我灰溜溜的走了,挥了挥衣袖,没带走一毛钱.

如果没有这倒霉的天气,相信今天一切都是完美的.记得哪位大师说过:这倒霉的事来了,可都是一串一串的来.我想说:你他妈的说的太对了,靠他奶奶的大腿.

如果你现在问我happy是什么,我会告诉你,是h a p p y这5个倒霉的字母.

如果你现在问我unlucky是什么,我会说:

是倒霉的体育馆

是倒霉的牛排面

是倒霉的delete操作

是倒霉的破job

是倒霉的手机

是倒霉的天气

是倒霉的鞭炮

是倒霉的雨伞

是倒霉的指头

只倒霉的砖头

是倒霉的司机

是倒霉的老板

现在,我会在任何词 句子前面加上倒霉两字,不过,这话我只是今天说,只是今天.

经过今天的事,我更加确信了一点:在爱情的海洋里,我注定是一艘破船,经常被淹没,从未靠过岸.

端午假期第一天:

09年的端午下着小雨,约了几个人去参加摇滚音乐节,结果都夭折了,我下定决心,自己陪自己去听音乐节.王啸坤 俞思远 五行乐队注定是配角,当信出场时,全场沸腾,我用手中的camon录下了<离歌>.我要说今晚我很high.美好的记忆注定是短暂的.

端午假期第二天:

第一次去了游泳馆,全馆里只有我抱着游泳圈,汗...我承认我是只汗鸭子,是一辈子的汗鸭子.我在水中注定是无助的.我放弃.因为我今天又了两口水(小曲这倒霉孩子说可能有人在游泳池中洒了尿)

端午假期第三天:

这一天注定是难忘的一天.约好跟小曲去爬山,这倒霉孩子让我在KFC等了他一个小时,约好了9点,他10点才来.真枉费了我9点就给他买好汉堡的一片心.这倒霉孩子.之后我们跳上了奔向抱犊寨的公交车.从下公交车开始,两个女孩子就引起了我的注意,其中有个很纯的女孩,纯洁的不忍去破坏.在爬山的过程中,我故意跟她们搭讪,然后就认识了,一起爬山,一起游玩了抱犊寨.一切都按照电影剧情走.在下山的缆车上,我知道了她叫雨.从下缆车之前,我觉得今天发生的一切都是对的,但是在回程的公交车上,我问了雨

冰:你有男朋友么?

雨:有

冰:真的假的?

雨:点了点头

雨:你有对象么?

冰:我要是有,就不会跟我旁边的那个男人出来玩了.

雨:会心的笑了笑.

冰:你把手机拿出来,我把我的电话告诉你,以后有事你可以找我.

但我没要雨的电话,我觉得那是多余的了.

从那刻起,我觉得原来之前发生的一切都是错误的包括在KFC等了一小时,吃了一个该死的汉堡,跳上了那辆不该出现的破车,还跟一个倒霉孩子出来玩.不过我很享受这段过程,真的很享受,特别是坐缆车的时候,很享受.因为在缆车上,我问了她的名字,她叫雨,我说我们一定很有缘分,因为我叫冰.

虽然一切都结束了,但是我不后悔,至少我努力过了,今天我很happy.

下了公交,我想体面的结束这一切:很高兴认识你们俩,今天跟你们玩得很高兴.

说完这句话,我们相互挥了挥手.此刻,我突然特别想念麻辣小龙虾还有啤酒,然后跟小曲暴走了N多路,在路上,我也跟小曲真诚的谈了今天发生的事还有他最近的情感困扰,我提了我的建议,我觉得他能找到一个更好的.朋友在这刻显得最珍贵.然后我急头白脸的狂吃了一盆麻辣小龙虾,这种又麻又辣的感觉真爽.这是我的第一次小龙虾.very good.

很喜欢王若林的<迷宫>,这首歌就是我现在的背景音乐.我突然很讨厌'对象'这个词.

最近我时常想一个问题:如果上帝再给我一次机会,我会选择重新再活一遍.

昨天:james最后一秒投中制胜三分

今天:kobe=41 points,ariza steal the game 3.

昨天:游魂演绎了宅男的无聊一天

今天:游魂脱掉外套,第一次去了植物园,第一次打了网球,第一次吃了SJZ最hot的白老太烧烤.

昨天:沃尔夫斯堡创造奇迹

今天:知道grassroot叫做'草根'

昨天:不敢看关于鲁能的TV和net,现在我的字典中山东鲁能=傻逼

今天:终于试着看了鲁能的TV和net,伤痕已去.你太让支持你的球迷失望了.鲁能,sorry,我戒了.

昨天和今天已成为历史,上帝也不会给我重生的机会,所以,我不会再让明天只有黑和白.

I just wanna change my life.

对于一个奔三的人,生活已过三分之一,回头想想,都觉得对不起自己,真想钻进时光机器,重新再活一边.哎,可惜小叮当只会出现在动画中,还是不要做卡通梦了.有了愧疚,自然想好好补偿一下自己,我的想法很简单:为自己做一顿早餐.我隐约记得上次给自己做早餐大概还在上初中吧,哎,想想也是,这么多年了都没认真体会过'生活'两字的涵义,再愧疚一下.由于手头缺乏炊具和各种调料,所以煮面条自然是唯一选择了,于是我买了,8毛钱的面条,1块钱的生菜,5毛钱的鲜蒜,一包醋,还有一瓶豆瓣酱.虽然我不怎么做饭,但是我对自己的厨艺还是相当的自信.开水放入面条,熟了后放生菜,顺便加了点方便面调料.然后鲜蒜切成块用醋拌,最后就着豆瓣酱,听起来似乎还不错噢.很享受这顿早餐,只不过一会要含上口香糖.

其实,最近状态一直不好,不太想碰oracle,渐渐放慢了前进的脚步.很迷茫,本来规划好了未来,可是现实往往那么残酷,我似乎又要重蹈覆辙了,过了这段时间,我一定要给自己放个假,好好思考一下.

最近又有几个朋友领了结婚证.

经典的纵贯线，如雷贯耳。经典铸就品质，品质决定命运，但命运确常常跟人开玩笑。

五一过后就感冒了，生怕自己得了猪流感，但如果公然去医院检查，似乎显得太贪生怕死，因为让我担心的是那几天面对面的接触了一个美国人，还有在餐厅里遇到了一个日本人，这两种人都不太让人放心，所以我一直有顾虑，不过吃了大量药后，病恙已去。但是心情一直不好，没有心情学习，对任何事情都失去了兴趣，浑浑噩噩。遇到了很多事，

1.偶然遇到以前的同事，但她确落荒而逃，误解很深呀。希望你能理解我的难处。

2.一直跟培训学校玩猫捉老鼠的游戏，只有四个字：你丫没品。

3.又见OCP，自信一下没了，基础没打牢啊。

4.公司经常给我其他客户的问题处理，有点失措。

生活节奏太快之后，独处一下进行调节似乎是不错的主意，但是我恰恰相反，独处太多了，反而没有了调节生活节奏的办法。突然一下想到很多网名很适合我：我叫很郁闷 你不懂我的郁闷 郁闷是我女朋友。

我得换一换环境了，要不然我还真会出现在北京的安定医院。差点忘了，点一下主题，现在很喜欢听《最近比较烦》。

SQL> startup
ORACLE instance started.

Total System Global Area 2248146944 bytes
Fixed Size 2074448 bytes
Variable Size 452987056 bytes
Database Buffers 1778384896 bytes
Redo Buffers 14700544 bytes
Database mounted.
ORA-00600: internal error code, arguments: [kcrfr_update_nab_2],
[0x7000000905969E8], [2], [], [], [], [], []

call stack:

ksedmp kgerinv kgeasnmierr kcrfr_update_nab kcrfr_read kcrfr_read_buffer
kcrfrgv kcratr1 kcratr kctrec kcvcrv kcfopd
adbdrv opiexe opiosq kpooprx kpoal8 opiodr

I found similar bugs with: 5692594, 6655116, 5364658

Symptoms

After applying a patchset, the post install documentation instructs you to run the $ORACLE_HOME/rdbms/admin/catpatch.sql script. The script does not run and instead produces the error below:

SQL> @catpatch.sql
SP2-0734: unknown command begining "catpatch.s..." ....

Cause

Solution

The problem is with the display terminal keyboard settings. The sqlplus session had trouble interpreting the "@" sign, because it was assigned in the terminal to the "kill" setting. The catpatch.sql script was supposed to be run as "@catpatch.sql" and since the "@" sign had a completely different meaning for this OS session, sqlplus only saw "catpatch.sql".

The solution is to change the display terminal keyboard setting of the kill character to something else. For example:

# stty kill ^u

After making this change the script is interpreted correctly and runs as it should.

http://blog.chinaunix.net/u/3380/showart_190946.html