由于删除oracle cluster sofeware时候误删除了inittab文件
在系统重启时候报错，提示找不到启动模式，找不到inittab
———————————————————–
这时候可以进去rescue模式补救
我这里的经过是这样的：
插入安装光盘，修改cdrom为第一启动模式，
进入到安装界面，输入 linux recsue
在配置网卡那段可以跳过，直接进去到补救模式的系统
这时候挂在原有系统
chroot /mnt/sysimage
挂载完之后
启动网络服务和telnet服务
service network start
service xinetd start
然后 telnet进来
vi /etc/inittab
把别的机子上的inittab复制过来，保存
重启，机子
MYSQLDUMP
在linux下的mysql在刚安装时候的默认用户都是root
导出的语句
mysql -uusername -ppassword -hlocalhost database_name > name.sql
导入的语句
mysql -uusername -ppassword -hlocalhost database_name < name.sql
SQL> create table t1 (t_id number);
Table created.
SQL> select index_name from user_indexes where table_name=’T1′;
no rows selected
SQL> insert into t1 values(110);
1 row created.
SQL> insert into t1 values(120);
1 row created.
SQL> insert into t1 values(130);
1 row created.
SQL> insert into t1 values(140);
1 row created.
SQL> create index idx_t1_id on t1(id) online;
create index idx_t1_id on t1(id) online
*
ERROR at line 1:
ORA-00904: “ID”: invalid identifier
SQL> create index idx_t1_id on t1(t_id) online;
Index created.
SQL> select * from t1;
T_ID
———-
110
120
130
140
SQL> commit
2 ;
Commit complete.
SQL> alter table t1 add constraint pk_t1_id primary key(t_id) enable validate;
Table altered.
SQL> insert into t1 values(110);
insert into t1 values(110)
*
ERROR at line 1:
ORA-00001: unique constraint (LUDA.PK_T1_ID) violated
SQL>
enable validate 是对当前存在的数据进行唯一性效验。如果当前表中存在重复数据，那么添加pk_t1_id的主键就会出错。
下面来测试
enable novalidate
SQL> drop table t1
2 ;
Table dropped.
SQL>
SQL> create table t1 (t_id number);
Table created.
SQL> insert into t1 values(110);
1 row created.
SQL> insert into t1 values(120);
1 row created.
SQL> insert into t1 values(120);
1 row created.
SQL> insert into t1 values(130);
1 row created.
SQL> create index idx_t1_id on t1(t_id);
Index created.
SQL> alter table t1 add constraint pk_t1_id primary key(t_id) enable validate;
alter table t1 add constraint pk_t1_id primary key(t_id) enable validate
*
ERROR at line 1:
ORA-02437: cannot validate (LUDA.PK_T1_ID) – primary key violated
SQL> alter table t1 add constraint pk_t1_id primary key(t_id) enable novalidate;
Table altered.
SQL> insert into t1 values(120);
insert into t1 values(120)
*
ERROR at line 1:
ORA-00001: unique constraint (LUDA.PK_T1_ID) violated
SQL>
这里novalidate的作用就是不对旧的数据进行效验，只对新加进来的数据进行效验。
前几天一个客户反应系统时间比现实晚一个小时，导致无法刷卡。因为oracle的时间是通过获取系统当前时间
11月6号。
当时我查了下发现是AIX系统开启夏令时导致的
echo $TZ
beist-8TD
————-
在aix 5.3补丁打齐下可以使用命令
chtz beist-8
修改。
或者直接修改/etc/environment
TZ=Beist-8
或者smit 里修改。
—————————————–
在aix6.1系统中推荐使用后面的2种方法修改，修改后建议重启AIX
aix p570，oracle 925
首先检查v$datafile_header，发现checkpoint_change#都是一致的。
于是按着一般的当前在线日志文件损坏步骤处理：
增加下列参数至Oracle启动文件:
_allow_resetlogs_corruption=TRUE
_corrupted_rollback_segments=(list of all your rollback segments)
注释掉启动文件中的rollback_segments参数或undo_tablespaces参数
startup mount
recover database until cancel
alter database open resetlogs;
一般情况下，open resetlogs后最容易出现的600号错误为ora-600 [2662]和ora-600 [2256]。这两个错误也相对来说好处理一些，只需要采用10015事件adjust scn号即可。
但是这次我却是碰到了ora-600 [4000]号错误。
Errors in file /home/oracle/app/oracle/admin/test/udump/test_ora_2838638.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Mon Feb 13 04:01:22 2011
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 2838638
metalink上对该错误的解释是：
DESCRIPTION:
This has the potential to be a very serious error.
It means that Oracle has tried to find an undo segment number in the
dictionary cache and failed.
ARGUMENTS:
Arg [a] Undo segment number
FUNCTIONALITY:
KERNEL TRANSACTION UNDO
IMPACT:
INSTANCE FAILURE – Instance will not restart
STATEMENT FAILURE
由于一开始_corrupted_rollback_segments里面只是列到_syssmu20$，于是将它列到_syssmu60$。重试后还是报这个错。
增加10513事件，禁止smon进程回滚，结果还是一样。
在600号的Trace文件中有：
ORA-00600: internal error code, arguments: [4000], [46], [], [], [], [], [], []
Current SQL statement for this session:
select ctime, mtime, stime from obj$ where obj# = :1
于是我怀疑会不会是undo$基表中没有46号回滚段的信息？
采用bbed检查undo$表格，发现里面是有这个回滚段的信息。
于是我想这个错误是出现在访问obj$基表上面，也就是说该表格的scn号与系统当前的scn号是不一致的。于是我想偿试修改该块的scn号。依然采用bbed，偿试修改该块的scn号。修改后，结果还是一样的。
于是我想应该是obj$基表上还有一个未提交的事务。于是继续查看trace文件，发现如下信息：
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x002e.025.00005b2c 0x00800f78.080c.01 –U- 1 fsc 0x0000.c5b527cf
data_block_dump,data header at 0x700000001f6e044
===============
tsiz: 0x1fb8
hsiz: 0xea
pbl: 0x700000001f6e044
bdba: 0x0040007a
76543210
flag=——–
很明显，是有一个未提交的事务，用bbed修改该事务的状态，将该事务改成提交状态。
首先找到itl信息:find /x 00005b2c，找到flag状态，现在其状态是20，也就是未提交，将之修改为80(提交状态)，并修改checkval。
之后去掉所有隐含参数，正常启动数据库，发现后台报出了ora-600[2662]错误。哈哈，事情至此就好办了，采用10015 adjust scn号，正常启动数据库：
Mon Feb 14 15:47:23 2011
Completed: ALTER DATABASE OPEN
Mon Feb 14 15:47:23 2011
Fatal internal error happened while SMON was doing active transaction recovery.
Mon Feb 14 15:47:23 2011
Errors in file oracle/admin/test/bdump/test_smon_2293872.trc:
ORA-00600: internal error code, arguments: [ktpridestroy2], []
SMON: terminating instance due to error 600
Instance terminated by SMON, pid = 2293872
从这块日志可以看出数据库正常启动后，马上因为smon回滚又导致了实例宕下来。
增加10513事件，启动数据库，一切正常。
想drop tablespce undotbs1，但是报出59号回滚段还有active事务无法删除。
于是增加_corrupted_rollback_segments参数，将数据库启来，新建一个回滚表空间，将原来的回滚表空间重建后，一切正常。
