用ORACLE8i修复数据库坏块的三种方法

在进行SUN CLUSTER双机切换、意外断电或其它情况下，有时会发生共享盘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=

转载：junzhongxu.cnblogs.com

实际项目中可使用的性能需求

在编写合同或者招标书时，经常有性能需求方面的章节。在编写这部分内容时，文档撰写人经常会觉得无从下手。

笔者根据实际工作中碰到的项目，将实际项目中可能使用性能需求进行汇总。仅供参考，不当之处，还望大家见谅。

性能需求一般包括：

1)列出有各种性能要求的功能，如有并发要求的功能及相应的并发要求、有响应时间要求的功能，

2)数据库容量，或指定时间的业务处理量，

3)系统用户容量的需求，

4)如果有机器配置上的要求，则说明相应的机器配置要求；

5)网络环境，如1MADSL或者512k拨号上网环境，

6)系统运行时间，如7×24小时不间断运行，或者可连续运行一周。

附：性能测试需求例子

项目1：

1. 时间特性的要求：

1)普遍情况下：

●搜索时间最大不超过5秒

●平均时间在1～3秒以内

2)1860前台（业务知识库）：

●知识文档的搜索不超过1秒

●知识文档的搜索与打开合计时间不超过3秒

●平均在1秒内

2. 系统容量要求

●静态用户（注册用户）：3500以上

●动态用户（在线用户）：1500以上

●并发数：500以上

项目2：

●检查系统在 2000 个用户的负载下，所有业务动作是否可用及稳定；

●检查系统在2000 个用户的负载下，连续运行 72 小时过程中，订单上传、转单、详情单查询、发运、勾核、签收及邮路填报功能等业务动作是否可用及稳定；

●检查系统在 1500 个用户、500 个并发用户操作的负载下，连续运行 72 小时过程中，以上业务动作是否可用及稳定；

●检查系统在 8.0 GB 业务数据、1500 个用户、500 个并发用户运行的负载下，连续运行 72 小时过程中，以上业务动作是否可用及稳定；

实际项目中可使用的性能需求

在编写合同或者招标书时，经常有性能需求方面的章节。在编写这部分内容时，文档撰写人经常会觉得无从下手。

笔者根据实际工作中碰到的项目，将实际项目中可能使用性能需求进行汇总。仅供参考，不当之处，还望大家见谅。

性能需求一般包括：

1)列出有各种性能要求的功能，如有并发要求的功能及相应的并发要求、有响应时间要求的功能，

2)数据库容量，或指定时间的业务处理量，

3)系统用户容量的需求，

4)如果有机器配置上的要求，则说明相应的机器配置要求；

5)网络环境，如1MADSL或者512k拨号上网环境，

6)系统运行时间，如7×24小时不间断运行，或者可连续运行一周。

附：性能测试需求例子

项目1：

1. 时间特性的要求：

1)普遍情况下：

●搜索时间最大不超过5秒

●平均时间在1～3秒以内

2)1860前台（业务知识库）：

●知识文档的搜索不超过1秒

●知识文档的搜索与打开合计时间不超过3秒

●平均在1秒内

2. 系统容量要求

●静态用户（注册用户）：3500以上

●动态用户（在线用户）：1500以上

●并发数：500以上

项目2：

●检查系统在 2000 个用户的负载下，所有业务动作是否可用及稳定；

●检查系统在2000 个用户的负载下，连续运行 72 小时过程中，订单上传、转单、详情单查询、发运、勾核、签收及邮路填报功能等业务动作是否可用及稳定；

●检查系统在 1500 个用户、500 个并发用户操作的负载下，连续运行 72 小时过程中，以上业务动作是否可用及稳定；

●检查系统在 8.0 GB 业务数据、1500 个用户、500 个并发用户运行的负载下，连续运行 72 小时过程中，以上业务动作是否可用及稳定；

实际项目中可使用的性能需求

在编写合同或者招标书时，经常有性能需求方面的章节。在编写这部分内容时，文档撰写人经常会觉得无从下手。

笔者根据实际工作中碰到的项目，将实际项目中可能使用性能需求进行汇总。仅供参考，不当之处，还望大家见谅。

性能需求一般包括：

1)列出有各种性能要求的功能，如有并发要求的功能及相应的并发要求、有响应时间要求的功能，

2)数据库容量，或指定时间的业务处理量，

3)系统用户容量的需求，

4)如果有机器配置上的要求，则说明相应的机器配置要求；

5)网络环境，如1MADSL或者512k拨号上网环境，

6)系统运行时间，如7×24小时不间断运行，或者可连续运行一周。

附：性能测试需求例子

项目1：

1. 时间特性的要求：

1)普遍情况下：

●搜索时间最大不超过5秒

●平均时间在1～3秒以内

2)1860前台（业务知识库）：

●知识文档的搜索不超过1秒

●知识文档的搜索与打开合计时间不超过3秒

●平均在1秒内

2. 系统容量要求

●静态用户（注册用户）：3500以上

●动态用户（在线用户）：1500以上

●并发数：500以上

项目2：

●检查系统在 2000 个用户的负载下，所有业务动作是否可用及稳定；

●检查系统在2000 个用户的负载下，连续运行 72 小时过程中，订单上传、转单、详情单查询、发运、勾核、签收及邮路填报功能等业务动作是否可用及稳定；

●检查系统在 1500 个用户、500 个并发用户操作的负载下，连续运行 72 小时过程中，以上业务动作是否可用及稳定；

●检查系统在 8.0 GB 业务数据、1500 个用户、500 个并发用户运行的负载下，连续运行 72 小时过程中，以上业务动作是否可用及稳定；

压力测试的几种常见性解决方案

并发性(压力测试）指的是多个用户试图同时访问相同数据的处理，问题的关键在于如何设计应用程序对并发性问题的处理方式，特别是当前很多系统都存在多用户对共享资源的访问，常见的解决方案如下：1：保守方法：这种并发性模型在数据上加了锁，如一个用户在操作数据库的一条记录时，在允许编辑的环境中，系统就会拒绝来自其它用户读取数据的请求。对于很可能出现一个以上用户同时编辑相同数据的情况时，最适合采用这种方式，虽然这种方式在实现上有一定的复杂度。在此模式下测试并发性主要关心的是验证能否正确地取得、释放加在记录上的锁，并且正确处理应用程序中所有可能更新这条记录的部分。a :锁的获得：因为同一时刻只有一个用户能够进入一条数据记录或数据项的更新状态，所以关键是系统必须把锁正确地分配给第一个请求的用户。获得锁的操作应该是可操作的，具体的做法是：让两个用户试图同时进入编辑状态或者也可以使用大量的请求，对于后者我们可以使用一个脚本来产生多个同时的编辑数据请求，以此来验证只有一个请求获得成功。b :锁的效用：验证锁的有效性必须确保其它任何用户不能用任何方式修改这个数据（如修改和删除），具体的验证方法是：让一个用户打开一条记录（进入编辑模式并且保持这个状态），同时其它用户在应用程序的所有地方试图编辑、删除等一切方法更新数据，系统应该拒绝所有其它用户更新数据的企图。c :锁的释放：必须验证：当编辑数据的用户释放了该条记录后，系统能够让其它用户编辑该条记录，另一个注意的方面是错误处理，也就是持有锁的用户用到错误的情况下（如客户端崩溃），系统应该完成什么样的操作，系统从释放锁的故障中重新恢复的能力要重点考虑。2：开放方式：在此模式中，总是允许用户读取数据，甚至还可能允许更新数据，但当用户试图保存数据时，系统会自动检查自从这个用户检索数据以后是否有其它人更新过数据，如果数据发生了变化，那么更新就失败。这种方法比保守模型允许更多的用户查看数据，所以它适用于不太可能出现多人同时修改同一数据的情况。在此模式下，更新是唯一需要关注的要点，最佳的测试方法是综合手动和自动测试技术，在手动测试时，两个测试人员编辑数据，然后试图同时保存数据，一个用户更新的操作成功后，另一个用户得到的消息是内容是其它用户已经更新了数据，此时他只有重新装载数据并且重新完成修改操作。在使用自动海量的测试方法时，同理，只有一个用户能更新记录，而其它用户都收到提示，因为其它用户已经更新了数据，所以他的操作无效。3：无并发保护，是所有模式中最简单的一种，通俗的说即胜利属于最后一个用户，但当两个用户同时修改一条记录时，可能导致数据损坏。在此模式下，无论更新请求的顺序如何，所有用户都该成功完成更新操作，特别需要关注的是数据的完整性和更新错误，如：当一个用户更新某记录的同时，它确被删除了。处理并发测试时还要注意，当相同的数据可以通过不同的界面或者功能更新时，应该测试所有可能访问这条记录的功能。 转自：http://www.cnblogs.com/junzhongxu/archive/2008/07/09/1238691.html