仓酷云
标题:
MYSQL编程：用ORACLE8i修单数据库坏块的三种办法
[打印本页]
作者:
小妖女
时间:
2015-1-16 22:43
标题:
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
珍贵的资金可以用于其他业务的启动，诸如市场、广告或调研和开发等。
作者:
admin
时间:
2015-1-19 21:47
作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！
作者:
飘飘悠悠
时间:
2015-1-25 22:32
备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。
作者:
冷月葬花魂
时间:
2015-2-4 09:29
索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。
作者:
蒙在股里
时间:
2015-2-9 21:24
数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。
作者:
老尸
时间:
2015-2-27 22:00
语句级快照和事务级快照终于为SQLServer的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！
作者:
莫相离
时间:
2015-3-9 14:49
是否碎片会引发效率问题？这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。
作者:
海妖
时间:
2015-3-16 23:54
原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。
作者:
若相依
时间:
2015-3-23 07:16
是要和操作系统进行Socket通讯的场景。否则建议慎重！
欢迎光临 仓酷云 (http://ckuyun.com/)
Powered by Discuz! X3.2