MYSQL编程：用ORACLE8i修单数据库坏块的三种办法

根据Evans的调查报告，“MySQL的使用在未来将继续呈成长趋势。”oracle|数据|数据库
在举行SUNCLUSTER双机切换、不测断电或别的情形下，偶然会产生共享盘MOUNT不上的情形，必要利用FSCK对共享盘举行修复。修复完成后，在数据库启动过程当中，却又呈现"数据块破坏，没法启动数据库"的征象，此时，能够依据分歧的数据块破坏范例，检测并修复毛病。在此先容三种利用Oracle8i修复破坏数据块的办法。

1、数据块破坏，毛病代码为ORA-01578

ORA-1115I/OERRORREADINGBLOCK

一般后跟ORA-737X毛病与操纵体系毛病（如UNIX中的毛病号5）

发生缘故原由：

1．硬件成绩（磁盘把持器成绩或磁查询题）

2．物理级的数据块破坏（一般由前一缘故原由形成）

3．处置巨型文件时，后跟毛病代码ORA-7371

断定妨碍缘故原由与恢复的办法：

1．检察alert.log文件中别的ORA-1115毛病的产生情形：

1）假如指向分歧磁盘的文件，则是磁盘把持器的成绩，检察V$DATAFILE，有哪些文件位于该把持器下，转到第二步。

2）假如指向不异磁盘的分歧文件，则是磁盘的成绩，转到第二步。

3）假如指向统一个文件，实行以下语句查找文件名：

SELECTSEGMENT_NAME,SEGMENT_TYPEFROMDBA_EXTENTSWHEREFILE_ID=<文件号>AND<块号>BETWEENBLOCK_ID
ANDBLOCK_ID+BLOCKS-1;

个中，文件号与块号是ORA-1115中指出的，假如该查询延续指向某表或索引，则重修它们便可。

2．假如文件是SYSTEM表空间，或处于NOARCHIVELOG形式，封闭数据库，转到第四步。

3．假如数据库处于ARCHIVELOG形式，仍应封闭数据库，假如不克不及封闭数据库，则将响应的数据文件脱机：ALTERDATABASEDATAFILE文件名OFFLINE；

4．试着将数据文件拷贝到其余磁盘。

5．假如拷贝失利，则文件将丧失。

6．STARTUPMOUNT;

7．将数据文件重定名为乐成拷贝到其余磁盘的文件名：

ALTERDATABASERENAMEFILE老路径文件名TO新路径文件名;

8．ALTERDATABASEOPEN;

9．RECOVERDATAFILE文件名;

ALTERDATABASEDATAFILE文件名ONLINE;

2、回滚段必要恢复

假如回滚段处于NEEDRECOVERY形态，必要实行以下步骤举行恢复：

1．检察一切联机的表空间与数据文件

2．在init.ora文件中到场event="10015tracenamecontextforever,level10"，这将天生一个追踪文件，个中含有事件与回滚的信息。

3．封闭偏重新翻开数据库。

4．检察TRACE文件，应有errorrecoverytx(#,#)object#.TX(#,#)，指失事务信息，个中object#与sys.dba_objects中的object_id不异。

5．利用以下查询找出正在举行恢复的工具：

SELECTowner,object_name,object_type,statusFROMdba_objectsWHEREobject_id=<object#>;

6．必需删除该工具以开释回滚块。

3、检测与修复破坏块的经常使用办法：

（一）利用初始化参数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．利用以下语句查询块破坏信息：

SELECTobject_name,relative_file_no,block_id,marked_corrupt,corrupt_description,repair_descriptionFROMrepair_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）SELECTindex_name,count(*)FROMorphan_key_tableWHEREtable_name=CLASSESGROUPBYindex_name;

（4）重修具有orphankeys的索引

限定：不克不及剖析Index-organizedtables与LOBindexes，DUMP_ORPHAN_KEYS不克不及对bitmap与function-basedindexes操纵。

（三）利用SQL命令ANALYZETABLE|INDEX…VALIDATESTRUCTURE

utlvalid.sql.创立含有破坏块信息的INVALID_ROWS表，ANALYZETABLEVALIDATESTRUCTURECASCADE同时校验表与索引。

（四）利用DBVERIFY

DBVERIFY是一个内部工具，以是对数据库影响很小。可用于在将备份文件拷贝回原地位前查验备份文件的无缺性，并定位数据块破坏。命令以下：

dbv/opt/oracle/db02/oradata/data01.dbfstart=1end=500logfile=dbv.log

珍贵的资金可以用于其他业务的启动，诸如市场、广告或调研和开发等。

作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。

索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。

数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。

语句级快照和事务级快照终于为SQLServer的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！

是否碎片会引发效率问题？这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

是要和操作系统进行Socket通讯的场景。否则建议慎重！