2010年09月03日

today, I use Ajax to develop KPI web system. and an error happened(sys.WebForms.PageRequestManagertimeoutException).

Action:

to enlarge attribute asyncpostbacktimeout as 600. the default time is 90s.

2007年05月08日

「宁」姓是当今中国姓氏排行第一百八十七位的姓氏,人口较多,约占全国汉族人口的百分之零点零五。

寻根溯源  宁姓来源有四:1、春秋时卫大夫宁俞之后。2、出自姬姓。据《姓氏急就篇·注》及《姓氏考略》所载,文王之子卫康叔之后有卫成公,成公封其子季〓于宁邑(今河南修武),子孙以邑为氏(实与①相矛盾,宁俞为卫成公时忠臣,成公不可能把一地封于两人,与古制不符)。3、出自嬴姓。据《元和姓纂》所载,宁与秦同姓,秦襄公曾孙谥宁公,支庶以谥为氏。4、出自他族改姓而来。清满洲八旗姓宁古塔氏、宁佳氏等均有改为宁姓者;今满、蒙古等少数民族均有此姓。

得姓始祖  宁俞。即宁武子,春秋时卫国人,卫文公、成公时大夫。成公无道为晋所攻,失国奔楚、陈,卒为晋侯所执。宁俞不避艰险,周旋其间,卒保其身,而济其君。孔子曰:“邦有道则智,邦无道则愚。其智可及也,其愚不可及也。”因宁俞机智果敢,忠心耿耿,故后世宁姓尊宁俞为其得姓始祖。

繁衍播迁  宁姓发源于春秋时卫国之宁邑,得姓不久,便风光显赫,见诸史册者有宁俞(宁武子)及其子宁相,宁殖(宁惠子)及其子宁喜(宁悼子),宁速(宁庄子)等均为卫大夫,另有被放逐于秦的卫国大夫宁跪,这样宁跪子孙和秦宁公之支庶便在陕西相融合,另宁戚仕于齐,子孙便落籍山东。战国时,有周威王师、赵国中牟(今属河南)人宁越,秦时有魏(今河北临漳)人宁昌,东阳(今安徽天长)人宁君,西汉时有东平亢父(今山东济宁)人宁寿,南阳穰(今河南邓州)人宁成,东汉有朝歌(今河南淇县)人宁季,广汉(今属四川)人宁叔。这些史实表明,在两汉时宁姓已分布于今河南、河北、陕西、山东等黄河中下游省份,并有进入安徽、四川等南方省份者。魏晋南北朝时,宁姓曾繁盛于今山东济南一带,故后世宁姓有以济南为其郡望堂号的。当然,这一时期的宁姓也同其他中原士族一样,有避乱南迁进入今湖北、湖南、江苏、浙江、江西等省份者,就连祖国西南端的广西也有了宁姓人家的足迹。隋唐两代,宁姓名人再次多见于史册,一改魏晋南北朝时期沉顿的局面,使宁姓发展呈现新局面。两宋以后,宁姓人南迁者渐渐多起来,并逐渐播迁于广东、福建。明初,山西宁姓作为洪洞大槐树迁民姓氏之一,被分迁于江苏、安徽、浙江、河南、山东、河北、北京等地。明中叶以后,有河北、京津等地之宁姓进入山海关以北繁衍生息,并有四川、广西之宁姓入迁云贵。张献忠屠川后,有湖南、湖北之宁姓填四川。清康乾年间以后,山东、河北、河南之宁姓随闯关东的风潮进入辽宁、吉林等地,并有闽粤沿海之宁姓入居台湾,山西之宁姓入迁内蒙,陕西之宁姓进入甘肃。如今,宁姓在全国分布较广,尤以吉林、陕西、湖南、山西、河北、河南等省多此姓,上述六省之宁姓约占全国汉族宁姓人口的百分之六十三。

郡望堂号  宁姓在长期的繁衍播迁过程中,形成的郡望主要有:济南郡——汉代设置。治所在东平陵(故城在今山东章丘西),晋移治历城(今山东济南)。辖境相当今山东济南、章丘、济阳、邹平等地。

堂号:“济南”、“宽廉”、“解衣”等。

宗族特征  1、宁姓济济多才,早在先秦时期,其名人便竞现史册。2、宁之古体有两种写法,一作宁,乃秦宁公之支庶,一作甯,乃卫康叔之后,但如果追根溯源的话,他们统统都是黄帝之裔,又加后俱简化为宁,所以宁姓人更无须分彼此了。3、曾任齐国上卿的卫国人宁戚,他用来打动齐桓公的歌曲可以说是古代较早的一首诗。歌曰:“南山矸白石烂,中有鲤血长尽半,生不逢尧与舜……,长夜漫漫何时旦。”

名人精粹  宁戚:卫国人,春秋时齐国大夫。他怀才不遇,隐于商贾,宿齐东门外。桓公外出他正在喂牛,叩角而歌。桓公闻而异之,谋于管仲。管仲根据他的擅长,向桓公推荐,遂任为大田(农官),后拜为大夫。宁成:南阳穰(今河南邓州)人,西汉酷吏。贪暴残酷,武帝时任内史,后畏罪解脱归家。再起为关都尉。人说:“宁成治,如狼牧羊。”宁纯:钦州钦江(今属广西)人,唐代官吏。世为俚帅。父为宁宣,隋时为合浦太守。唐高祖武德中归唐。父亡后,以纯为越州刺史。善抚众,能以诗书教其宗人,民俗向化,徙刺合州。宁赓:鄱阳(今江西波阳)人,唐代官吏。僖宗广明中黄巢起兵,赓与弟宁衮统乡兵拒之,守饶、歙二州。官至御史大夫。宁涛:华州华阴(今属陕西)人,宋代画家。善画,师范宽,多作关右风景,以精雅称。宁智:绛州曲沃(今属山西)人,北宋学者。举乡贡进士。通《五经》,教授晋绛。其德性学问,为时所重。宁时凤:饶州浮梁(今属江西)人,南宋官吏。进士出身,官蕲春主簿。金兵至,众皆惊惧,独时凤慷慨陈词,卒死于难。宁玉:孟州河阳(今河南孟县)人,元代将领。膂力绝人,从世祖渡江有功,授百夫。后攻襄樊、灭南宋,累官浙西道都元帅兼沿海上万户。宁正:凤阳府寿州(今属安徽)人,明初将领。沉着有胆略,随朱元璋征讨四方,并屯田数万顷,兵农饶足,积功至四川都指挥使,后守云南。宁钦:湖广衡阳(今属湖南)人,明代官吏。正德时为御史,谏武宗南巡。又奏革吉王府渔税,定递马之制,减带征之数。宁完我:辽宁辽阳人,清初大臣。天命间归降后金,后隶汉军正红旗。皇太极授为参将。后抚明朝百姓,主张仿明制,访六部、言官,又献灭明之策,皆被采纳。顺治时起为大学士、《明史》总裁官等。宁调元:湖南醴陵人,近代资产阶级革命者、诗人。留日期间入同盟会,民国成立后,任广东三佛铁路总办。后因参加二次革命,被袁世凯所杀。有《太一遗书》。

2007年05月07日

这个五一不太闲
       公司五一准备服务器升级,当我们听到这个消息,就知道这个五一没得玩了。
任务:
          升级EMC SAN 存储。由500G扩到 2190G(2T).
          重新划分存储单元LUN
          重做OFS
时间:
        五一全假
引子:
         DELL 工程师将赴现场实施EMC SAN扩容,并重新划分LUN。我们(包括Boss)负责DB,OFS,DB TEST,DB Performance Tuning

硬件部分略。。。

软件部分
       经过几天的讨论,我们与DELL 工程师以及Singapore来的Senior级人物就方案做了好几套,风险评估也讨论了好久。(像我们这种电子产品制造企业,数量惊人,光服务器就有10台,DB有35个独立数据库,对数据的安全非常重视)。
Oracle OFS只是针对Windows平台。并且它必须与Windows Cluster (MCSC)一起使用。OFS只是一种容错技术,就是我们常说的双机集群(Double-Host Cluster)。当一台DB服务挂了后,OFS自动切换到另一台服务器,保证了业务的正常,不间断运行。RAC也是一种集群技术,但它比OFS功能不仅是强大,而且是不同一个层次。OFS可以免费使用,但RAC必须单独向ORACLE购买。RAC是将任务分布给集群中的每个结点,它能自自动根据必能,资源情况分布任务,当一台服务器性能变底时,它会将任务转移给其他结点服务器执行;当一台服务器挂了后,它将分配给集群中的其他结点,这里就好比OFS的容错功能。

Windows Cluster (MCSC)
 there are 3 DELL PowerEdge 6850 Server.Firstly,Dell Enginer re-creating EMC SAN.and split it into 3 Driver Slot.重建SAN,并划分成3个存储槽。

Configure Windows Cluster

Install Oracle 9i

Install OFS

详细信息,请参考: 
 http://www.oracle.com/technology/global/cn/tech/windows/failsafe/index.html

 

2007年05月05日

意外删除Oracle数据文件(dbf),恢复oralce库的解决办法

系统环境:
1、操作系统:Windows 2000 Server,
2、数据库: Oracle 8i R2 (8.1.6) for NT 企业版
3、安装路径:C:\ORACLE

错误现象:
因误操作,数据库中某一数据文件被误删,
控制面板的Oracle相关服务显示已启动,但用SQL*Plus无法连接,
显示以下错误
ORA-01033: ORACLE initialization or shutdown in progress

模拟现象:

create tablespace test datafile
‘c:\test.ora’ size 5M
AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED
default storage (initial 128K next 1M pctincrease 0)
/

关闭所有服务stop.bat

net stop "OracleWebAssistant0"
net stop "OracleOraHome81TNSListener"
net stop "OracleServiceORADB"

shutdown

在操作系统中删除test.ora文件

重新启动服务start.bat

net start "OracleWebAssistant0"
net start "OracleOraHome81TNSListener"
net start "OracleServiceORADB"

服务里OracleServiceORADB显示已启动,但用SQL*Plus无法连接,
显示ORA-01033: ORACLE initialization or shutdown in progress

解决方法:

先让该数据文件脱机,就可以打开数据库
C:\>svrmgrl
svrmgrl>connect internal/oracle
svrmgrl>shutdown
svrmgrl>startup mount

–ARCHIVELOG模式命令,文件名要大写
svrmgrl>alter database datafile ‘C:\TEST.ORA’ offline;

–NOARCHIVELOG模式命令
svrmgrl>alter database datafile ‘C:\TEST.ORA’ offline drop;

svrmgrl>alter database open;

–查询数据文件联、脱机状态
SQL> select file#,name,status from v$datafile;

SQL> drop tablespace test;

表空间已丢弃。

 

意外删除Oracle数据文件(dbf),恢复oralce库的解决办法

系统环境:
1、操作系统:Windows 2000 Server,
2、数据库: Oracle 8i R2 (8.1.6) for NT 企业版
3、安装路径:C:\ORACLE

错误现象:
因误操作,数据库中某一数据文件被误删,
控制面板的Oracle相关服务显示已启动,但用SQL*Plus无法连接,
显示以下错误
ORA-01033: ORACLE initialization or shutdown in progress

模拟现象:

create tablespace test datafile
‘c:\test.ora’ size 5M
AUTOEXTEND ON NEXT 1M MAXSIZE UNLIMITED
default storage (initial 128K next 1M pctincrease 0)
/

关闭所有服务stop.bat

net stop "OracleWebAssistant0"
net stop "OracleOraHome81TNSListener"
net stop "OracleServiceORADB"

shutdown

在操作系统中删除test.ora文件

重新启动服务start.bat

net start "OracleWebAssistant0"
net start "OracleOraHome81TNSListener"
net start "OracleServiceORADB"

服务里OracleServiceORADB显示已启动,但用SQL*Plus无法连接,
显示ORA-01033: ORACLE initialization or shutdown in progress

解决方法:

先让该数据文件脱机,就可以打开数据库
C:\>svrmgrl
svrmgrl>connect internal/oracle
svrmgrl>shutdown
svrmgrl>startup mount

–ARCHIVELOG模式命令,文件名要大写
svrmgrl>alter database datafile ‘C:\TEST.ORA’ offline;

–NOARCHIVELOG模式命令
svrmgrl>alter database datafile ‘C:\TEST.ORA’ offline drop;

svrmgrl>alter database open;

–查询数据文件联、脱机状态
SQL> select file#,name,status from v$datafile;

SQL> drop tablespace test;

表空间已丢弃。

 

实例学习Oracle错误:日志损坏
原文:ORA-00320 cannot read file header from log string of thread string
  Cause The file is not available.

  Action Restore the log file.

  ORA-00320 无法从thread1的log1中读取文件头

  原因:文件已丢失

  解决方案:重新提取日志文件。

  ORA-00321 log string of thread string, cannot update log file header

  Cause Cannot write to the log file.

  Action Restore access to the file.

  ORA-00321: 无法更新日志的文件头

  原因:无法写入该日志文件

  解决方案:重新读取该日志文件

  ORA-00312 online log string thread string: ’string’

  Cause This message reports the file name for details of another message.

  Action Other messages will accompany this message. See the associated messages for the appropriate action to take.

  ORA-00312:联机日志错误

  原因:消息内容错乱,为其他消息的相关描述。

  解决方案:日志消息冲突。察看与相关动作匹配的消息。

  ORA-00313 open failed for members of log group string of thread string

  Cause The online log cannot be opened. The file may not be in the expected location.

  Action Specify the correct redo log file or make the log available, if necessary. Also, see the accompanying messages.

  ORA-00313: 日志组中数据文件丢失或出错

  原因:日志组中的日志文件无法被打开。

  解决方案:确保读取日志文件路径的正确性或重建日志文件。

  案例一:获取Oracle错误信息——数据库和网站崩溃

  错误描述:我使用的是Oracle 8.1.7.0.1,得到了如下的错误信息:

  ORA-00320 can not read file header from log 1 thread 1

  ORA-321 ORACLE_HOME Redo1.log

  ORA-27091: skgfqio: unable to queue I/O

  附加信息:我的操作系统是RedHat Linux ,我想知道如何进行修正才能让数据库和我们的网站再一次正常工作。

  解决方案:你的数据库缺少了一个现在redo日志。要纠正这个问题,按照以下的步骤在SQL*Plus 或者 SVRMGRL 中进行如下操作:

  1. CONNECT / AS SYSDBA

  2. STARTUP MOUNT

  3. RECOVER DATABASE UNTIL CANCEL;

  4. CANCEL (at first prompt)

  5. ALTER DATABASE OPEN RESETLOGS;

  当你用RESETLOGS启动数据库的时候,它会重新创建丢失的在线redo日志文件。此时,立即关闭数据库,并且进行良好的备份!如果你不这样做的话,你就不能恢复过去的resetlogs操作。

 

 

  案例二:日志损坏

  环境描述:linux 9 oracle9

  错误描述:今天不小心把名为redo01.log、redo02.log、redo03.log的三个文件请空了。

  结果数据库报错如下

  ORA-00320: cannot read file header from log 2 of thread 1

  ORA-00312: online log 2 thread 1: ‘/opt/app/oracle/oradata/actdb/redo02.log’

  ORA-27091: skgfqio: unable to queue I/O

  ORA-27069: skgfdisp: attempt to do I/O beyond the range of the file

  Additional information: 1

  Additional information: 1

  如何解决呢?

  解决方案:联机日志分为当前联机日志和非当前联机日志,非当前联机日志的损坏是比较简单的,一般通过clear命令就可以解决问题。

  损坏非当前联机日志:

  1、启动数据库,遇到ORA-00312 or ORA-00313错误,如:

  ORA-00313: open failed for members of log group 4 of thread 1

  ORA-00312: online log 3 thread 1: ‘/opt/oracle/db04/oradata/ORCL/redo03.log’

  从这里我们知道日志组1的数据文件损坏或丢失了

  从报警文件可以看到更详细的信息

  2、查看V$log视图:

  SQL> select group#,sequence#,archived,status from v$log;

  GROUP# SEQUENCE# ARC STATUS

  ———- ———- — —————-

  1 54 YES INACTIVE

  2 55 NO CURRENT

  3 53 YES INACTIVE

  可以知道,该组是非当前状态,而且已经归档。

  3、用CLEAR命令重建该日志文件

  SQL>alter database clear logfile group 3;

  如果是该日志组还没有归档,则需要用

  SQL>alter database clear unarchived logfile group 3;

  4、打开数据库,重新备份数据库

  SQL>alter database open;

  说明:

  1)、如果损坏的是非当前的联机日志文件,一般只需要clear就可以重建该日志文件,但是如果该数据库处于归档状态但该日志还没有归档,就

  需要强行clear。

  2)、建议clear,特别是强行clear后作一次数据库的全备份。

  3)、此方法适用于归档与非归档数据库。

  损坏当前联机日志:

  归档模式下当前日志的损坏有两种情况,

  一、是数据库是正常关闭,日志文件中没有未决的事务需要实例恢复,当前日志组的损坏就可以直接用alter database clear unarchived

  logfile group n来重建。

  二、是日志组中有活动的事务,数据库需要媒体恢复,日志组需要用来同步,有两种补救办法

  A. 最好的办法就是通过不完全恢复,可以保证数据库的一致性,但是这种办法要求在归档方式下,并且有可用的备份

  B. 通过强制性恢复,但是可能导致数据库不一致。

  下面分别用来说明这两种恢复方法

  1 通过备份来恢复

  1、打开数据库,会遇到一个类似的错误

  ORA-00313: open failed for members of log group 1 of thread 1

  ORA-00312: online log 1 thread 1: ‘D:\ORACLE\ORADATA\TEST\REDO01.LOG’

  ORA-27041: unable to open file

  OSD-04002: unable to open file

  O/S-Error: (OS 2) 系统找不到指定的文件

  2、查看V$log,发现是当前日志

  SQL> select group#,sequence#,archived,status from v$log;

  GROUP# SEQUENCE# ARCHIVED STATUS

  ———- ———- ——– —————-

  1 1 NO CURRENT

  2 2

  YES INACTIVE

  3 3 YES INACTIVE

  3、发现clear不成功

  SQL> alter database clear unarchived logfile group 1;

  alter database clear unarchived logfile group 1

  *

  ERROR at line 1:

  ORA-01624: log 1 needed for crash recovery of thread 1

  ORA-00312: online log 1 thread 1: ‘D:\ORACLE\ORADATA\TEST\REDO01.LOG’

  4、拷贝有效的数据库的全备份,并不完全恢复数据库

  可以采用获取最近的SCN的办法用until scn恢复或用until cnacel恢复

  recover database until cancel

  先选择auto,尽量恢复可以利用的归档日志,然后重新

  recover database until cancel

  这次输入cancel,完成不完全恢复,也就是说恢复两次。

  如:

  SQL> recover database until cancel;

  Auto

  ……

  SQL> recover database until cancel;

  Cancel;

  5、利用alter database open resetlogs打开数据库

  说明:

  1、这种办法恢复的数据库是一致的不完全恢复,会丢失当前联机日志中的事务数据

  2、这种方法适合于归档数据库并且有可用的数据库全备份。

  3、恢复成功之后,记得再做一次数据库的全备份。

  4、建议联机日志文件一定要实现镜相在不同的磁盘上,避免这种情况的发生,因为任何数据的丢失对于生产来说都是不容许的。

  如果没有备份,进行强制性恢复

  1、打开数据库,会遇到一个类似的错误

  ORA-00313: open failed for members of log group 1 of thread 1

  ORA-00312: online log 1 thread 1: ‘D:\ORACLE\ORADATA\TEST\REDO01.LOG’

  ORA-27041: unable to open file

  OSD-04002: unable to open file

  O/S-Error: (OS 2) 系统找不到指定的文件

  2、查看V$log,发现是当前日志

  SQL> select group#,sequence#,archived,status from v$log;

  GROUP# SEQUENCE# ARCHIVED STATUS

  ———- ———- ——– —————-

  1 1 NO CURRENT

  2 2 YES INACTIVE

  3 3 YES INACTIVE

  3、发现clear不成功

  SQL> alter database clear unarchived logfile group 1;

  alter database clear unarchived logfile group 1

  *

  ERROR at line 1:

  ORA-01624: log 1 needed for crash recovery of thread 1

  ORA-00312: online log 1 thread 1: ‘D:\ORACLE\ORADATA\TEST\REDO01.LOG’

  4、把数据库down掉

  SQL>shutdown immediate

  5、在init.ora中加入如下参数

  _allow_resetlogs_corruption=TRUE

  6、重新启动数据库,利用until cancel恢复

  SQL>recover database until cancel;

  Cancel

  如果出错,不再理会,发出

  SQL>alter database open resetlogs;

  7、数据库被打开后,马上执行一个full export

  8、shutdown数据库,去掉_all_resetlogs_corrupt参数

  9、重建库

  10、import并完成恢复

  11、建议执行一下ANALYZE TABLE …VALIDATE STRUCTURE CASCADE;

  说明:

  1、该恢复方法是没有办法之后的恢复方法,一般情况下建议不要采用,因为该方法可能导致数据库的不一致

  2、该方法也丢失数据,但是丢失的数据没有上一种方法的数据多,主要是未写入数据文件的已提交或未提交数据。

  3、建议成功后严格执行以上的7到11步,完成数据库的检查与分析

  4、全部完成后做一次数据库的全备份

  5、建议联机日志文件一定要实现镜相在不同的磁盘上,避免这种情况的发生,因为任何数据的丢失对于生产来说都是不容许的

oracle数据块损坏后的修复方法
方法1:
D:\>sqlplus "/ as sysdba"
SQL*Plus: Release 9.0.1.0.1 – Production on Wed Sep 29 13:51:48 2004

(c) Copyright 2001 Oracle Corporation.  All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.0.1.1.1 – Production
With the Partitioning option
JServer Release 9.0.1.1.1 – Production

SQL> select name from v$datafile;

NAME
————————————————-

D:\ORACLE\ORADATA\ORCL\SYSTEM01.DBF
D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF
D:\ORACLE\ORADATA\ORCL\INDX01.DBF
D:\ORACLE\ORADATA\ORCL\TOOLS01.DBF
D:\ORACLE\ORADATA\ORCL\USERS01.DBF
D:\ORACLE\ORADATA\ORCL\OEM_REPOSITORY.DBF
D:\ORACLE\ORADATA\ORCL\TEST.DBF
D:\ORACLE\ORADATA\ORCL\TEST1.DBF
D:\ORACLE\ORADATA\ORCL\RMANTS.DBF
D:\ORACLE\ORADATA\ORCL\EXPERT.DBF
D:\ORACLE\ORADATA\ORCL\DBO.DBF
D:\ORACLE\ORADATA\ORCL\NMS.DBF
D:\ORACLE\ORADATA\ORCL\WACOS.DBF
D:\ORACLE\ORADATA\ORCL\RBS.DBF
D:\ORACLE\ORADATA\ORCL\IPAS_USG_DATA.DBF
D:\ORACLE\ORADATA\ORCL\IPAS_USG_IDX.DBF
D:\ORACLE\ORADATA\ORCL\DSF.DBF

17 rows selected.

SQL> create tablespace block datafile ‘D:\ORACLE\ORADATA\ORCL\block.dbf’ size 2M;

Tablespace created.

SQL> create user chenfeng identified by chenfeng default tablespace block
temporary tablespace temp;

User created.

SQL> alter user chenfeng quota unlimited on block;

User altered.

SQL> grant dba to chenfeng;

Grant succeeded.

SQL> connect chenfeng/chenfeng
Connected.

SQL> create table t as select * from dba_users;

Table created.

SQL> insert into t select * from t;

24 rows created.

SQL> /

48 rows created.

SQL> /

96 rows created.

SQL> /

192 rows created.

SQL> /

384 rows created.

SQL> /

768 rows created.

SQL> /

1536 rows created.

SQL> /

3072 rows created.

SQL> /
insert into t select * from t
*
ERROR at line 1:
ORA-01653: unable to extend table CHENFENG.T by 256 in tablespace BLOCK

SQL> commit;

Commit complete.

SQL> alter system checkpoint;

System altered.

SQL> select count(*) from t;

  COUNT(*)
———-
      6144

SQL> create index i_username on t(username);

Index created.

SQL> connect / as sysdba
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

关闭数据库后用Ultredit编辑block.dbf文件,随便更改几个字符来模拟块损坏。

SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.

Total System Global Area  114061244 bytes
Fixed Size                   282556 bytes
Variable Size              79691776 bytes
Database Buffers           33554432 bytes
Redo Buffers                 532480 bytes
Database mounted.
Database opened.

SQL> connect chenfeng/chenfeng
Connected.
SQL> select count(*) from t;
select count(*) from t
                     *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 18, block # 18)
ORA-01110: data file 18: ‘D:\ORACLE\ORADATA\ORCL\BLOCK.DBF’

SQL> show parameter db_block_size

NAME                                 TYPE        VALUE
———————————— ———– —–
db_block_size                        integer     4096

SQL>host
用dbv命令来检验坏块:

D:\>dbv file=D:\ORACLE\ORADATA\ORCL\BLOCK.DBF blocksize=4096

DBVERIFY: Release 9.0.1.1.1 – Production on Wed Sep 29 15:30:51 2004

(c) Copyright 2001 Oracle Corporation.  All rights reserved.

DBVERIFY – Verification starting : FILE = D:\ORACLE\ORADATA\ORCL\BLOCK.DBF
Page 16 is marked corrupt
***
Corrupt block relative dba: 0×04800010 (file 18, block 16)
Bad check value found during dbv:
Data in bad block -
 type: 30 format: 2 rdba: 0×04800010
 last change scn: 0×0000.00227604 seq: 0×1 flg: 0×04
 consistency value in tail: 0×76041e01
 check value in block header: 0xe4ce, computed block checksum: 0×1000
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 18 is marked corrupt
***
Corrupt block relative dba: 0×04800012 (file 18, block 18)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×04800012
 last change scn: 0×0000.00227646 seq: 0×2 flg: 0×04
 consistency value in tail: 0×76460602
 check value in block header: 0xad38, computed block checksum: 0×4870
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 45 is marked corrupt
***
Corrupt block relative dba: 0×0480002d (file 18, block 45)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×0480002d
 last change scn: 0×0000.0022769f seq: 0×1 flg: 0×06
 consistency value in tail: 0×769f0601
 check value in block header: 0×4af9, computed block checksum: 0×2005
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 95 is marked corrupt
***
Corrupt block relative dba: 0×0480005f (file 18, block 95)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×0480005f
 last change scn: 0×0000.0022769f seq: 0×1 flg: 0×06
 consistency value in tail: 0×769f0601
 check value in block header: 0xb609, computed block checksum: 0xc75e
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 97 is marked corrupt
***
Corrupt block relative dba: 0×04800061 (file 18, block 97)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×04800061
 last change scn: 0×0000.0022769f seq: 0×1 flg: 0×06
 consistency value in tail: 0×769f0601
 check value in block header: 0×6e6a, computed block checksum: 0×9b20
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 203 is marked corrupt
***
Corrupt block relative dba: 0×048000cb (file 18, block 203)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×048000cb
 last change scn: 0×0000.0022769b seq: 0×28 flg: 0×04
 consistency value in tail: 0×769b0628
 check value in block header: 0xeb1d, computed block checksum: 0×7520
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 243 is marked corrupt
***
Corrupt block relative dba: 0×048000f3 (file 18, block 243)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×048000f3
 last change scn: 0×0000.0022769b seq: 0×28 flg: 0×04
 consistency value in tail: 0×769b0628
 check value in block header: 0×1174, computed block checksum: 0×110
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 469 is marked corrupt
***
Corrupt block relative dba: 0×048001d5 (file 18, block 469)
Bad check value found during dbv:
Data in bad block -
 type: 0 format: 2 rdba: 0×000001d5
 last change scn: 0×0000.00000000 seq: 0×1 flg: 0×05
 consistency value in tail: 0×00000001
 check value in block header: 0×6d5, computed block checksum: 0×1000
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

DBVERIFY – Verification complete

Total Pages Examined         : 512
Total Pages Processed (Data) : 249
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 35
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 17
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 203
Total Pages Marked Corrupt   : 8
Total Pages Influx           : 0

此时导出数据是不允许的:
D:\>exp chenfeng/chenfeng file=t.dmp tables=t

Export: Release 9.0.1.1.1 – Production on Wed Sep 29 15:34:15 2004

(c) Copyright 2001 Oracle Corporation.  All rights reserved.

Connected to: Oracle9i Enterprise Edition Release 9.0.1.1.1 – Production
With the Partitioning option
JServer Release 9.0.1.1.1 – Production
Export done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)

About to export specified tables via Conventional Path …
. . exporting table                              T
EXP-00056: ORACLE error 1578 encountered
ORA-01578: ORACLE data block corrupted (file # 18, block # 18)
ORA-01110: data file 18: ‘D:\ORACLE\ORADATA\ORCL\BLOCK.DBF’
Export terminated successfully with warnings.

检查损坏的对象,使用以下SQL:
SQL>SELECT tablespace_name, segment_type, owner, segment_name
FROM dba_extents where file_id = 18 and 18 between block_id AND block_id + blocks – 1;

TABLESPACE_NAME                SEGMENT_TYPE       OWNER
—————————— —————— —————————

SEGMENT_NAME
——————————
BLOCK                          TABLE              CHENFENG
T

设置内部事件,使exp时能跳过这些损坏的block:

SQL> ALTER SYSTEM SET EVENTS=’10231 trace name context forever,level 10′ ;

System altered.

SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

再导出表试一下:

D:\>exp chenfeng/chenfeng file=t.dmp tables=t

Export: Release 9.0.1.1.1 – Production on Wed Sep 29 15:47:17 2004

(c) Copyright 2001 Oracle Corporation.  All rights reserved.

Connected to: Oracle9i Enterprise Edition Release 9.0.1.1.1 – Production
With the Partitioning option
JServer Release 9.0.1.1.1 – Production
Export done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)

About to export specified tables via Conventional Path …
. . exporting table                              T       6004 rows exported
EXP-00091: Exporting questionable statistics.
Export terminated successfully with warnings.

结果导出了6004行数据。

D:\>exit

SQL> alter system set events=’10231 trace name context off’;   (关闭设置的event)

 System altered.

SQL> connect  chenfeng/chenfeng
Connected.

SQL> drop table t;

Table dropped.

SQL> host
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

D:\>imp chenfeng/chenfeng file=t.dmp tables=t

Import: Release 9.0.1.1.1 – Production on Wed Sep 29 15:50:53 2004

(c) Copyright 2001 Oracle Corporation.  All rights reserved.

Connected to: Oracle9i Enterprise Edition Release 9.0.1.1.1 – Production
With the Partitioning option
JServer Release 9.0.1.1.1 – Production

Export file created by EXPORT:V09.00.01 via conventional path
import done in WE8ISO8859P1 character set and AL16UTF16 NCHAR character set
import server uses ZHS16GBK character set (possible charset conversion)
. importing CHENFENG’s objects into CHENFENG
. . importing table                            "T"       6004 rows imported
Import terminated successfully without warnings.

SQL> select count(*) from t;

  COUNT(*)
———-
      6004

结果表明丢失了6144 – 6004 = 110 行数据。

方法2(dbms_repair):

D:\>sqlplus "/ as sysdba"

SQL*Plus: Release 9.0.1.0.1 – Production on Wed Sep 29 16:06:37 2004

(c) Copyright 2001 Oracle Corporation.  All rights reserved.

Connected to:
Oracle9i Enterprise Edition Release 9.0.1.1.1 – Production
With the Partitioning option
JServer Release 9.0.1.1.1 – Production

SQL>connect chenfeng/chenfeng

Connected.

SQL> select count(*) from t;

  COUNT(*)
———-
      6004

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

使用UltraEdit编辑block.dbf,修改几个字符模拟块损坏

SQL> startup
ORACLE instance started.

Total System Global Area  114061244 bytes
Fixed Size                   282556 bytes
Variable Size              79691776 bytes
Database Buffers           33554432 bytes
Redo Buffers                 532480 bytes
Database mounted.
Database opened.

SQL> select count(*) from t;
select count(*) from t
                     *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 18, block # 152)
ORA-01110: data file 18: ‘D:\ORACLE\ORADATA\ORCL\BLOCK.DBF’

D:\>dbv file=D:\ORACLE\ORADATA\ORCL\BLOCK.DBF blocksize=4096

DBVERIFY: Release 9.0.1.1.1 – Production on Wed Sep 29 16:41:40 2004

(c) Copyright 2001 Oracle Corporation.  All rights reserved.

DBVERIFY – Verification starting : FILE = D:\ORACLE\ORADATA\ORCL\BLOCK.DBF
Page 2 is marked corrupt
***
Corrupt block relative dba: 0×04800002 (file 18, block 2)
Bad check value found during dbv:
Data in bad block -
 type: 29 format: 2 rdba: 0×04800002
 last change scn: 0×0000.0022819b seq: 0×2 flg: 0×04
 consistency value in tail: 0×819b1d02
 check value in block header: 0×1f08, computed block checksum: 0×7000
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 4 is marked corrupt
***
Corrupt block relative dba: 0×04800004 (file 18, block 4)
Bad check value found during dbv:
Data in bad block -
 type: 30 format: 2 rdba: 0×04800004
 last change scn: 0×0000.002275f8 seq: 0×1 flg: 0×04
 consistency value in tail: 0×75f81e01
 check value in block header: 0xe4bc, computed block checksum: 0×8000
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 16 is marked corrupt
***
Corrupt block relative dba: 0×04800010 (file 18, block 16)
Bad check value found during dbv:
Data in bad block -
 type: 30 format: 2 rdba: 0×04800010
 last change scn: 0×0000.00227604 seq: 0×1 flg: 0×04
 consistency value in tail: 0×76041e01
 check value in block header: 0xe4ce, computed block checksum: 0×1000
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 152 is marked corrupt
***
Corrupt block relative dba: 0×04800098 (file 18, block 152)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×04800098
 last change scn: 0×0000.00227fae seq: 0×1 flg: 0×06
 consistency value in tail: 0×7fae0601
 check value in block header: 0xc082, computed block checksum: 0×2f
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 154 is marked corrupt
***
Corrupt block relative dba: 0×0480009a (file 18, block 154)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×0480009a
 last change scn: 0×0000.00227fae seq: 0×1 flg: 0×06
 consistency value in tail: 0×7fae0601
 check value in block header: 0×507c, computed block checksum: 0×7000
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 261 is marked corrupt
***
Corrupt block relative dba: 0×04800105 (file 18, block 261)
Bad check value found during dbv:
Data in bad block -
 type: 6 format: 2 rdba: 0×04800105
 last change scn: 0×0000.0022769b seq: 0×28 flg: 0×04
 consistency value in tail: 0×769b0628
 check value in block header: 0×117c, computed block checksum: 0×4050
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 396 is marked corrupt
***
Corrupt block relative dba: 0×0480018c (file 18, block 396)
Bad check value found during dbv:
Data in bad block -
 type: 0 format: 2 rdba: 0×0000018c
 last change scn: 0×0000.00000000 seq: 0×1 flg: 0×05
 consistency value in tail: 0×00000001
 check value in block header: 0×68c, computed block checksum: 0×400
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

Page 469 is marked corrupt
***
Corrupt block relative dba: 0×048001d5 (file 18, block 469)
Bad check value found during dbv:
Data in bad block -
 type: 0 format: 2 rdba: 0×000001d5
 last change scn: 0×0000.00000000 seq: 0×1 flg: 0×05
 consistency value in tail: 0×00000001
 check value in block header: 0×6d5, computed block checksum: 0×1000
 spare1: 0×0, spare2: 0×0, spare3: 0×0
***

 

DBVERIFY – Verification complete

Total Pages Examined         : 512
Total Pages Processed (Data) : 182
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 103
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 17
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 202
Total Pages Marked Corrupt   : 8
Total Pages Influx           : 0

使用dbms_repair包
1.创建管理表:
SQL> connect / as sysdba
Connected.

创建一个Repair 表:

SQL>BEGIN
DBMS_REPAIR.ADMIN_TABLES (
     TABLE_NAME => ‘REPAIR_TABLE’,
     TABLE_TYPE => dbms_repair.repair_table,
     ACTION     => dbms_repair.create_action,
     TABLESPACE => ‘USERS’);
END;
/

PL/SQL procedure successfully completed.

SQL> DESC REPAIR_TABLE Name                         Null?    Type —————————- ——– ————– OBJECT_ID                    NOT NULL NUMBER TABLESPACE_ID                NOT NULL NUMBER RELATIVE_FILE_ID             NOT NULL NUMBER BLOCK_ID                     NOT NULL NUMBER CORRUPT_TYPE                 NOT NULL NUMBER SCHEMA_NAME                  NOT NULL VARCHAR2(30) OBJECT_NAME                  NOT NULL VARCHAR2(30) BASEOBJECT_NAME                       VARCHAR2(30) PARTITION_NAME                        VARCHAR2(30) CORRUPT_DESCRIPTION                   VARCHAR2(2000) REPAIR_DESCRIPTION                    VARCHAR2(200) MARKED_CORRUPT               NOT NULL VARCHAR2(10) CHECK_TIMESTAMP              NOT NULL DATE FIX_TIMESTAMP                         DATE REFORMAT_TIMESTAMP                    DATE创建一个Orphan Key 表:

SQL>BEGIN
DBMS_REPAIR.ADMIN_TABLES (
     TABLE_NAME => ‘ORPHAN_KEY_TABLE’,
     TABLE_TYPE => dbms_repair.orphan_table,
     ACTION     => dbms_repair.create_action,
     TABLESPACE => ‘USERS’);
END;
/
PL/SQL procedure successfully completed.

SQL> DESC ORPHAN_KEY_TABLE Name                         Null?    Type —————————- ——– —————– SCHEMA_NAME                  NOT NULL VARCHAR2(30) INDEX_NAME                   NOT NULL VARCHAR2(30) IPART_NAME                            VARCHAR2(30) INDEX_ID                     NOT NULL NUMBER TABLE_NAME                   NOT NULL VARCHAR2(30) PART_NAME                             VARCHAR2(30) TABLE_ID                     NOT NULL NUMBER KEYROWID                     NOT NULL ROWID KEY                          NOT NULL ROWID DUMP_TIMESTAMP               NOT NULL DATE2.检查坏块:dbms_repair.check_object

SQL> SET SERVEROUTPUT ON
     DECLARE num_corrupt INT;
     BEGIN
     num_corrupt :=0;
     DBMS_REPAIR.CHECK_OBJECT(SCHEMA_NAME =>’CHENFENG’,OBJECT_NAME =>’T',REPAIR_TABLE_NAME =>’REPAIR_TABLE’,CORRUPT_COUNT =>num_corrupt);
     DBMS_OUTPUT.PUT_LINE(‘number corrupt:’ || TO_CHAR(num_corrupt));
     END;
     /

PL/SQL procedure successfully completed.

用创建的REPAIR_TABLE中查看块损坏信息:
SQL> SELECT object_name, relative_file_id, block_id,marked_corrupt, corrupt_description,repair_description,CHECK_TIMESTAMP from repair_table;

结果可以看到损坏的block的信息,这里得到的信息和我们用dbv看到的一致。
           
3.定位坏块:dbms_repair.fix_corrupt_blocks 

SQL> declare
  cc number;
  begin
  dbms_repair.fix_corrupt_blocks(schema_name => ‘CHENFENG’,object_name => ‘T’,fix_count => cc);
  dbms_output.put_line(a => to_char(cc));
  end;
   /

PL/SQL procedure successfully completed.

4.跳过坏块:
我们前面虽然定位了坏块,但是,如果我们访问table:

SQL> select count(*) from chenfeng.t;
select count(*) from chenfeng.t
                              *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 18, block # 152)
ORA-01110: data file 18: ‘D:\ORACLE\ORADATA\ORCL\BLOCK.DBF’

还是会得到错误信息。   
这里需要用skip_corrupt_blocks来跳过坏块:

SQL> exec dbms_repair.skip_corrupt_blocks(schema_name =>’CHENFENG’,object_name => ‘T’,flags => 1);

PL/SQL procedure successfully completed.

SQL> select count(*) from chenfeng.t;

  COUNT(*)
———-
      5926

丢失了6004-5926=78行数据。

5.处理index上的无效键值:dump_orphan_keys

SQL>declare
cc number;
begin
dbms_repair.dump_orphan_keys(schema_name =>’CHENFENG’,object_name => ‘I_USERNAME’,object_type => 2,
repair_table_name => ‘REPAIR_TABLE’,orphan_table_name => ‘ORPHAN_TABLE’,key_count => CC);
end;
/

PL/SQL procedure successfully completed.

SQL> select count(*) from ORPHAN_TABLE;

  COUNT(*)
———-
        78

和上面看到的损失的数据行数一致。

根据这个结果考虑是否需要rebuild index.

6.重建freelist:rebuild_freelists

SQL> exec dbms_repair.rebuild_freelists(schema_name =>’CHENFENG’,object_name =>’T');

PL/SQL procedure successfully completed.

附录(提供一篇经典案例):
在ALPHA服务器中使用ORACLE8i修复数据块的方法

通常使用ALPHA服务器的共享盘安装数据库的方式有两种:一种是将共享盘作为裸设备方式挂靠,数据库以OPS方式安装;另一种方式是将共享盘做成文件系统挂靠在一台服务器上,将数据库装在共享盘上,进行双机切换时,首先关闭数据库,从这台服务器卸下共享盘,再将其挂靠到另一台服务器上,再次启动数据库。在进行双机切换、意外断电或其它情况下,有时会发生共享盘脏,MOUNT不上的情况,需要使用FSCK对共享盘进行修复。修复完成后,在数据库启动过程中,却又出现"数据块损坏,无法启动数据库"的现象,此时,可以根据不同的数据块损坏类型,检测并修复错误。在此介绍三种使用Oracle8i修复损坏数据块的方法。

一、数据块损坏,错误代码为ORA-01578

ORA-1115 I/O ERROR READING BLOCK

通常后跟ORA-737X错误与操作系统错误(如UNIX中的错误号5)

产生原因:

1. 硬件问题(磁盘控制器问题或磁盘问题)

2. 物理级的数据块损坏(通常由前一原因造成)

3. 处理巨型文件时,后跟错误代码ORA-7371

确定故障原因与恢复的方法:

1. 查看alert.log文件中其它ORA-1115错误的发生情况:

1) 如果指向不同磁盘的文件,则是磁盘控制器的问题,查看V$DATAFILE,有哪些文件位于该控制器下,转到第二步。

2) 如果指向相同磁盘的不同文件,则是磁盘的问题,转到第二步。

3) 如果指向同一个文件,执行以下语句查找文件名:

SELECT SEGMENT_NAME,SEGMENT_TYPE FROM DBA_EXTENTS WHERE

FILE_ID=<文件号> AND <块号> BETWEEN BLOCK_ID AND

BLOCK_ID+BLOCKS-1;

其中,文件号与块号是ORA-1115中指出的,如果该查询持续指向某表或索引,

则重建它们即可。

2. 如果文件是SYSTEM表空间,或处于NOARCHIVELOG模式,关闭数据库,转到第四步。

3. 如果数据库处于ARCHIVELOG模式,仍应关闭数据库,如果不能关闭数据库,则将相应的数据文件脱机:ALTER DATABASE DATAFILE ‘文件名’ OFFLINE;

4. 试着将数据文件拷贝到别的磁盘。

5. 如果拷贝失败,则文件将丢失。

6. STARTUP MOUNT;

7. 将数据文件重命名为成功拷贝到别的磁盘的文件名:

ALTER DATABASE RENAME FILE ‘老路径文件名’ TO ‘新路径文件名’

8. ALTER DATABASE OPEN;

9. RECOVER DATAFILE 文件名;

ALTER DATABASE DATAFILE ‘文件名’ ONLINE;

二、回滚段需要恢复

如果回滚段处于NEED RECOVERY状态,需要执行以下步骤进行恢复:

1. 查看所有联机的表空间与数据文件

2. 在init.ora文件中加入event = "10015 trace name context forever,level 10",这将生成一个追踪文件,其中含有事务与回滚的信息。

3. 关闭并重新打开数据库。

4. 查看TRACE文件,应有error recovery tx(#,#) object #.TX(#,#),指出事务信息,其中object #与sys.dba_objects中的object_id相同。

5. 使用以下查询找出正在进行恢复的对象:

SELECT owner,object_name,object_type,status FROM dba_objects WHERE

object_id=<object #>;

6. 必须删除该对象以释放回滚块。

三、检测与修复损坏块的常用方法

(一)使用初始化参数DB_BLOCK_CHECKING与DB_BLOCK_CHECKSUM。

当块改变时,DB_BLOCK_CHECKING对块进行逻辑校验。将防止发生10210 与10211错误。

(二)使用DBMS_REPAIR包,由dbmsrpr.sql与prvtrpr.plb生成该包在特定表中生成损坏块的信息。

1.DBMS_REPAIR.ADMIN_TABLES用于创建与删除存储损坏块的表。其中TABLE_TYPE为:REPAIR_TABLE(表),ORPHAN_TABLE(索引);ACTION为:CREATE_ACTION(创建表),PURGE_ACTION(删除无关数据),DROP_ACTION(删除表)。例:

dbms_repair.admin_tables(‘REPAIR_TABLE’,DBMS_REPAIR.REPAIR_TABLE,DBMS_REPAIR.CREATE_ACTION,’temp_data’);

2.DBMS_REPAIR.CHECK_OBJECT检查表、索引、分区中的块损坏。其中OBJECT_TYPE为:TABLE_OBJECT(表),INDEX_OBJECT(索引), REPAIR_TABLE_NAME(用于存储损坏块信息的表)。例:

dbms_repair.check_object(‘ORATRAIN’,'LOCATIONS’,corrupt_count=>:cc);

3.使用以下语句查询块损坏信息:

SELECT object_name, relative_file_no, block_id,
marked_corrupt, corrupt_description, repair_description
FROM repair_table;

4.将块标志为损坏的:dbms_repair.fix_corrupt_blocks(‘ORATRAIN’,'LOCATIONS’,fix_count=>:fc);

5.跳过损坏块:dbms_repair.skip_corrupt_blocks(‘ORATRAIN’, ‘LOCATIONS’);

其中OBJECT_TYPE为 :TABLE_OBJECT(表),CLUSTER_OBJECT(索引)。

6.使用REBUILD_FREELISTS重建损坏的空闲列表:DBMS_REPAIR.rebuild_freelists

7.使用以下方法查找指向损坏块的索引:

(1) 创建存放指向坏块索引的表

(2) dbms_repair.dump_orphan_keys(‘ORATRAIN’,'LOC_PK’,

orphan_table_name=>’ORPHAN_TAB1′,key_count=>:kc);

(3) SELECT index_name, count(*) FROM orphan_key_table WHERE table_name = ‘CLASSES’ GROUP BY index_name;

(4) 重建具有orphan keys的索引

限制:不能分析Index-organized tables 与 LOB indexes,DUMP_ORPHAN_KEYS不能对bitmap与 function-based indexes操作。

(三)使用SQL命令ANALYZE TABLE|INDEX … VALIDATE STRUCTURE

utlvalid.sql.创建含有损坏块信息的INVALID_ROWS表,ANALYZE TABLE VALIDATE STRUCTURE CASCADE同时校验表与索引。

(四)使用DBVERIFY

DBVERIFY是一个外部工具,所以对数据库影响很小。可用于在将备份文件拷贝回原位置前检验备份文件的完好性,并定位数据块损坏。命令如下:

dbv /users/DB00/u03/data01.dbf start=1 end=500 logfile=dbv.log

2007年05月01日
一个农民娶刘亦菲的可行性报告
尊敬的领导冒号

    鄙人怀着无比激动的心情递交这份可行性研究报告,可能鄙人显得过于急切,但各位领导一定能理解一个长时间得不到安慰的单身大龄男青年的苦衷。首先鄙人要严正申明:鄙人的感情是非常真挚的!鄙人的身世是绝对清白的!鄙人每次看到亦菲娇美的面容都惊为天人:此女只应天上有,人间哪得几回见!鄙人对伊的感情苍天可鉴!令日月无光!天可崩、地可裂,此情不可灭!山无棱、天地合,不敢与伊绝!

    鄙人呕心沥血耗时约7200秒,翻遍我国《婚姻法》、《刑法》、《宪法》、《未成年人保护法》等诸多法律文献,综合运用ASEB栅格分析法、SWOT模型分析、回归理论等多种研究方法,最后终于得出下列刘亦菲成为我老婆的可行性研究成果:

    1、她是女,我是男,异性,不违反我国婚姻法。
    2、她未嫁,我未娶,单身,不存在破坏婚姻的罪过。
    3、她年满18,有完全民事责任权力,虽然有早婚嫌疑,但本人年过28,属于晚婚,平均一下有关部门应该可以谅解,岁月不饶人啊!
    4、她姓刘,我姓魏,绝对不存在任何血缘关系,可以绝对保证下一代的健康。
    5、俗话说“距离产生美”,我和刘亦菲之间绝对算得上最美,异常的美,美得让上帝都要亲自来撮合这段美好姻缘!
    6、她生在武汉,我出生地也离武汉不远,我们是老乡嫁老乡,亲上加亲,而且不会出现什么水土不服、沟通不畅的问题。
    7、她虽然目前暂时还不认识我,但我相信爱情的力量是伟大的,是神奇的,是无法用语言表述的,再说我们也可以继承我们伟大先辈的优秀革命传统:先结婚后恋爱!
    8、她身高169CM,我也是169CM,就这一点就足以让我热泪盈眶了:同志们啊!男女平等是祖祖辈辈多少代的呼唤啊!终于在我们的身上实现了!
    9、她属兔,我属虎,我禁不住再次热泪盈眶:小白兔和大老虎那是几千年的缘分啊!缘分啊!!
    10、她演戏,我砍柴,她演戏演得漂亮,我砍柴砍得潇洒,我们俩绝对是千百年最般配的狼柴女貌!
    11、她是处女座,我是处男座,我还能用什么话来说呢?我们纯纯的结合将象一道眩目的霹雳划开这污浊混沌的世界,从此,世界清净了!
    12、她的偶像就是我的偶像,哦不!是我的神明!她喜欢的歌星的歌我做梦都在唱;她喜欢的运动我天天练;她最喜欢的食物我当饭吃;她最喜欢的地方我买张地图天天看,而且还做笔记!

    尊敬的领导,相信我,TRUST ME!我会给她幸福,我会给她一切,月亮已经不能代表我的心!太阳也不能!您呼吸吧!呼吸吧!每一口空气中都饱含我对她的爱!对不起!温室效应不是我故意的,臭氧层空洞也是我不小心!总之,我做的事我来承担,只恳请您成全我们!

    当否,请批示!

 

oracle9i回滚段表空间数据文件损坏或丢失后的恢复方法

由于oracle回滚段表空间数据文件丢失导致数据库起不来,报ora-01157错误,对于回滚段数据文件丢失后的恢复,处理方法有很多,本例主要是用oracle隐含参数来恢复数据库的一个例子:

隐含参数的含义:

SQL> select KSPPDESC from X$KSPPI where ksppinm=’_corrupted_rollback_segments’;

KSPPDESC
—————————————————————-
corrupted undo segment list

具体操作步骤如下:

首先把初始化参数init.ora文件里自动管理改为手工管理,然后加入隐含参数:
#undo_management=AUTO
undo_tablespace=UNDOTBS
_corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)  

SQL>startup restrict  mount  (数据库启动到mount状态)
SQL> alter database datafile ‘D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF’ offline drop;
Database altered.

SQL>alter database open;
Database opened.
SQL> show parameter undo

NAME TYPE VALUE
———————————— ———– ———
undo_management string MANUAL
undo_retention integer 900
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS

SQL> drop tablespace undotbs including contents;  (假如回滚段里有活动事物,undo表空间可能会drop不掉,本例是回滚段里没有活动事物的时候)
Tablespace dropped.

重建undotbs表空间:
SQL> create undo tablespace undotbs datafile ‘D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF’
size 100M;
Tablespace created.

SQL> shutdown immediate  (关闭数据库)
Database closed.
Database dismounted.
ORACLE instance shut down.

编辑init.ora初始化参数文件,去掉隐含参数,设置
undo_management=AUTO
undo_tablespace=UNDOTBS
保存初始化参数init.ora文件,然后执行
SQL> startup mount
ORACLE instance mounted.
Total System Global Area 114061244 bytes
Fixed Size 282556 bytes
Variable Size 79691776 bytes
Database Buffers 33554432 bytes
Redo Buffers 532480 bytes
Database mounted.

SQL>alter database datafile ‘D:\ORACLE\ORADATA\ORCL\UNDOTBS01.DBF’ online;
Database altered.

SQL>alter database open;
Database opened.
SQL> show parameter undo

NAME TYPE VALUE
———————————— ———– ——————————
undo_management string AUTO
undo_retention integer 900
undo_suppress_errors boolean FALSE
undo_tablespace string UNDOTBS

建议用隐含参数将数据库open后,立刻做个exp全备,如果数据量不大的话,最好的方法是重新建库,将exp出来的数据再imp进新数据库里。

至此,数据库恢复完毕。此方法不到万不得已不建议采用,最好的方法是用以前的数据文件的备份来做恢复,因为用加隐含参数的方法将数据库打开后,此时数据库有可能数据会不一致,因为对于回滚段里有活动事物的时候,数据库可能会丢失一些数据,主要是回滚段里有活动事物的那部分数据,因此做好数据库的备份是至关重要的,这样对于恢复起来就很简单方便。

 

4/29 松山湖

昨夜不记时辰
网上闲逛识菁

似云,似菁
拨动我心
我的一片云

      这段时间心里颇不宁静,忽的坐立不安,忽的失去方向,总之一团糟。当我看到菁的名字,仿佛看到了一片绿绿,一片淡蓝的云,仿佛打了一剂镇心剂,豁然开朗。她能给我希望,激情,动力。