今天在测试环境操作时，手一抖在dbs目录下rm *了，当时心中一阵愕然，惨了库要挂
冷静一下，一来是测试环境，短期内不会有影响，有时间恢复，二来这个目录下的文件我还算了解，重做起来应该不会有太大难度
先想下这个目录下有什么关键的文件
1、参数文件，数据库初始化时要读的文件，关系到一些内存的分配，控制文件，归档日志这些东西
2、密码文件，这个东西最容易搞定
看下会带来什么影响，就目前来说，数据库是否还能使用
sqlplus / as sysdba
可以登陆，查表试试，发现报错，数据库没有打开
其实这个数据库已经挂掉了，不管是本地还是远程都是不能成功登陆的（sqlplus / as sysdba除外）
先把简单的搞定，重建密码文件,在dbs目录下执行
orapwd file=orapwtestbill password=oracle
我先尝试了下OS认证登了数据库，是成功的，没有问题
接下来就是尝试重建参数文件
我的数据库是10g的，如果是11g的直接使用:create spfile from memory;
10g的只能想办法重建
第一步，检查环境中有没有备份
在主机根目录，使用root用户，过程比较慢，找全点嘛，如果平时不动其他文件系统的话在oracle目录下就行了
find ./ -name *spfile*
这个命令直接没有结果，也就是我不可能直接拷出来用了，手工是免不了了
find ./ -name *init*
在/oracle/app/oracle/admin/tjbill/scripts目录下找到一个init.ora文件，这个应该是另外一个实例的参数文件备份，这个实例早就删除掉了，有残余的文件没有删除吧
不管怎么样咱们现在有个模板了，而且是同一台主机的，应该比较类似，先拷出来瞧瞧
第二步，造文件
把那个模板样的文件打开，首先把所有的实例名改掉 tjbill----->testbill
再看看重要的东西
db_block_size
control_files=("/billdb/controlfile/controlfile01.ctl", "/billdb/controlfile/controlfile02.dbf")
db_recovery_file_dest=/oraflash
db_recovery_file_dest_size=3219128320
sga
pga
这些既然是参数文件里的东东，都可以使用show parameter parameter_name查出来，现在也查不出来了，咋办呢
如果查不出来也不要紧，造呗
db_block_size 这个值一般都是8K
control_files命名的方式比较单一，记不得就在系统了find
归档也是类似的
sga和pga就稍微弄大点也没大问题，如果是现网环境这些绝对是有文档可查的，我这里测试环境平时也经常摸，都记得
其他的也就没什么了，搞定重启数据库呗
sqlplus / as sysdba进入数据库，关闭数据库，现在想shutdown immediate就别想了，应该是关不了的
先试下
SQL> shutdown immediate;
ORA-24324: service handle not
initialized
ORA-24323: value not allowed
ORA-01089: immediate shutdown in
progress - no operations are permitted
这堆乱七八糟的暂时不研究了，说起来得半天，退出来重新登下执行shutdown abort,不退出来直接强关会报没有权限的错
SQL> shutdown abort
ORACLE instance shut down.
好的，已经能够关掉了，起到nomount状态
SQL> startup nomount
ORACLE instance started.
Total System Global Area 1073741824 bytes
Fixed Size 2159912 bytes
Variable Size 266210008 bytes
Database Buffers 801112064 bytes
Redo Buffers 4259840 bytes
么有问题，看到有木有，我的参数文件造的很成功啊，得意下啊，起到mount状态
SQL> alter database mount ;
Database altered.
依旧么得问题啊，启动到open吧，保佑我一次搞定啊
SQL> alter database open ;
alter database open
*
ERROR at line 1:
ORA-16014: log 2 sequence# 44432 not archived, no available destinations
ORA-00312: online log 2 thread 1: '/billdb/redolog/redolog02.dbf'
又是万恶的错误啊，有日志没归档啊，没地方归档了，不是归档目录弄错了，就是空间有点小
先检查下目录没有问题啊，那就是空间的问题了
alter system set db_recovery_file_dest_size=5G scope=both;
都记得是这么改哈，能改掉才怪，我现在是pfile启动的撒，先建个spfile吧
create spfile from pfile;
发现oracle挺有意思啊，语句其实挺人性话的
关掉实例，再弄到nomount状态
alter system set db_recovery_file_dest_size=5G scope=both;
修改了，一路起，么得问题，远程登陆查询下表，也OK大功告成。
犯错误就得总结啊，我这也算犯错误啊
1、没事多备份这些个什么参数文件，控制文件的
2、遇事不能紧张，想清楚，总能解决的
最后，这个解决的方法应该很多啊，日志比较全的话，应该可以直接找到参数文件的
在$ORACLE_BASE/admin/$ORACLE_SID/bdump中有个alert_sid.log的文件里有每次启动的初始化过程，也是可以查看到的，只要不删除掉就会有
processes = 1500
sga_max_size = 6442450944
sga_target = 4294967296
control_files = /billdb/controlfile/controlfile01.ctl, /billdb/controlfile/controlfile02.dbf
db_block_size = 8192
db_writer_processes = 3
compatible = 10.2.0.4.0
db_files = 4096
db_file_multiblock_read_count= 16
db_recovery_file_dest = /oraflash
db_recovery_file_dest_size= 3219128320
undo_management = AUTO
undo_tablespace = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain =
session_cached_cursors = 200
utl_file_dir = /tmp
job_queue_processes = 10
cursor_sharing = SIMILAR
parallel_max_servers = 4
background_dump_dest = /oracle/app/oracle/admin/testbill/bdump
user_dump_dest = /oracle/app/oracle/admin/testbill/udump
core_dump_dest = /oracle/app/oracle/admin/testbill/cdump
audit_file_dest = /oracle/app/oracle/admin/testbill/adump
db_name = testbill
open_cursors = 800
pga_aggregate_target = 1073741824
阅读(4673) | 评论(1) | 转发(0) |
