Chanel [K]

面朝大海,春暖花开

Archive for the ‘Travel’ Category

Warm January in Sanya

with 13 comments

几乎没有享受过如此暖和的1月份,在临近春节的时候可以穿着短裤短袖四处走动,这样的感觉实在奇妙。

在三亚住的地方远离市区,位于田独镇,四周是乡村,但是只要走出房门站在宽宽的走廊上看出去,就是湛蓝的天空和不远处的青山,每当午后,阳光充足,暖风习习。

IMG_0750

从楼下门口的小路走出去,大概不要10分钟,就是田独镇的大街,往山的方向去是亚龙湾,那里水天一线。

IMG_0736

大街的左侧是田独市场,到了晚上是熙熙攘攘的夜市,夜里11点钟,从家里走出来,牵着老婆的手晃晃悠悠,随便找一处大排档,吃上些烧烤,再来一个新鲜的金椰,插着吸管,你一口我一口,再惬意的生活也不过如此吧。

IMG_0787

驱车20分钟到达亚龙湾,游人们都买票从大门进去,我们在三亚呆久了,觉得自己是半个本地人,就熟门熟路从旁边的小道进去,一家人都省了门票,占老大便宜了。:D

IMG_0778

海边堆沙子,玩累了,就冒充旁边酒店的客人,躺在酒店专属的遮阳伞下的长椅上,感觉自己的皮肤一点一点被晒黑,海风吹过卷起地上的细沙扑打在脚面上,房山人从此改叫三亚人了。

Written by kamus

January 24th, 2010 at 5:41 pm

Posted in Travel

ORA-00064 When Oracle Database Instance Startup

with 9 comments

根据Metalink Bug 5455094的解释,在Oracle9iR2 RAC环境中,如果db_cache_size + db_keep_cache_size总共超过了50G,那么数据库实例就会在启动的时候报ORA-00064错误,无法正常启动。

00064, 00000, “object is too large to allocate on this O/S (%s,%s)”
// *Cause: An initialization parameter was set to a value that required
// allocating more contiguous space than can be allocated on this
// operating system.

Metalink上的建议是:
1. 降低cache size(这是一个很扯淡的建议,直接无视)
2. 设置_ksmg_granule_size到一个比较大的值,比如_ksmg_granule_size=67108864,实测结果当设置该参数之后,数据库性能低下,反应缓慢。

客户的这个环境,数据库SGA设置高达200G,以上两种方法都不能使用,却可以通过土办法来曲线救国。

1. 设置SGA_MAX_SIZE = 200G,这个参数不会触发Bug 5455094。
2. 设置db_cache_size为一个较小的值,以不触发Bug为标准。
3. 在每次实例启动之后,脚本自动执行用alter system命令将buffer cache扩大。

ALTER system SET db_cache_size = 214753888696 scope=memory;

Written by kamus

May 18th, 2009 at 11:41 am

Posted in Oracle RDBMS, Travel

Tagged with

How to recover data with DUL after table dropped

with 12 comments

首先系统情况如下:
1. Oracle版本是9.2.0.8,操作系统是IBM AIX
2. 数据文件存储在裸设备上
3. 被删除的表是分区表
4. 数据库非归档,没有任何备份
5. 在误drop table以后,立刻将包含该表的表空间offline了,并且保留了当时的current online redo文件
6. 保留了之前建表时的create脚本

恢复过程如下:
1. DUL使用的init.dul内容:

osd_big_endian_flag=true
osd_dba_file_bits=10
osd_c_struct_alignment=32
osd_file_leader_size=1
osd_word_size=32
 
control_file=/tmp/control.dul
db_block_size=8192
compatible=9

2. DUL使用的control.dul文件内容

58 58 /somepath/rawdevice1 4096 blocks 4095873
58 110 /somepath/rawdevice2 4096 blocks 639873
58 126 /somepath/rawdevice3 4096 blocks 255873

第1位是TS#,第2位是RFILE#,第3位是数据文件全路径,第4位是在AIX系统中裸设备需要跳过的字节,第5位是数据文件的真实block数(从v$datafile中以size/db_block_size获得)。

第4,5两位在数据文件为裸设备的情况下才需要,否则在scan database时扫描到裸设备结尾的时候,将可能报错。

3. 通过logminer得到被drop掉的表分区的data object id(因为被drop了,因此无法从system数据字典中获得)。如何使用Logminer不在本文范围内。
比如最后看到SQL_REDO字段的结果是类似于这样的输出:

DELETE FROM "SYS"."OBJ$" WHERE "OBJ#" = '25514' AND "DATAOBJ#" = '25514' ......

那么就可以知道data object id = 25514

4. 登录DUL

DUL> scan database;
DUL> unload table table_name partition(p_name) 
(col_name1 VARCHAR2(6),col_name2 VARCHAR2(17),col_name3 VARCHAR2(3).....) 
storage (dataobjno 25514);

这里的table_name和p_name其实都可以随便写,甚至不写partition也可以,最主要的是dataobjno必须正确,就可以unload出表数据。当然还必须有表结构,否则会报告无法在OBJ$中找到相应表。

如果此处没有事先保留的create table脚本,而且也不知道表中有哪些字段,那么工作量就大了。
基本步骤如下:

DUL> alter session set use_scanned_extent_map = true;
DUL> scan database;
DUL> scan tables;

然后在dul.log中查找上面的data object id,找到的话,将会是类似于下面的输出:

UNLOAD TABLE OBJNO25514 ( COL001 VARCHAR2(6), COL002 VARCHAR2(17), COL003 VARCHAR2(3)
        , COL004 VARCHAR2(26), COL005 VARCHAR2(30), COL006 NUMBER, COL007 NUMBER
        , COL008 VARCHAR2(1), COL009 NUMBER, COL010 VARCHAR2(38) )
    STORAGE( DATAOBJNO 25514 );

同时为了保险起见,在scan tables的过程中,DUL在log中还显示了该表的前5行记录内容,可以比对一下看看是否确实是被误删除的表。

之后,就是根据对于业务的了解,重新构建表结构了,其实对于只是删除了一张表而言,工作量还可以接受,但是如果是删除了整个USER …

5. 之后就是用sqlldr重新加载数据的事情了,不再赘述。

DUL格言是:Life without DUL

错误时刻都可能发生,为了数据的安全,为了自己工作饭碗的安全,还是做好备份吧。

Written by kamus

May 16th, 2009 at 11:41 am

Posted in Oracle RDBMS, Travel

Tagged with