fastt200 + oracle8.1.7

jun_xiang

前日到客户处更换fastT200硬盘的时候，不幸发生了，想想现在都后怕。
客户的fastt200共有六块盘，前34G的4块盘做RAID5并划出2快逻辑盘，后两块73G的盘做RAID1，后发现RAID1中的一块盘坏掉，导致raid降级，需要更换，而且cache电池也报警，也需要更换。但是我当时没有和73一样大的盘，只有一块一百多个G的盘，当时也没有怎么考虑就给换上了，可没有想到的是，在静静的等待后，RAID5中的一块逻辑盘失败了。这样导致挂在存储上的数据库也启动不了，后来怎么也恢复不了，又oracle数据库用的是裸设备，哎……数据等于就是洗白了

。但是我还是不怎么明白为什么会出现这种情况，现将当时fastt200log文件贴出，望大家能指点迷津：
DetailsStorage Subsystem:
Array: 1
RAID level: 5
Logical Drives: data1, data2
Status: Failed
Failed Logical Drive - Drive Failure
What Caused the Problem?
One or more drives in the array have failed, causing the associated logical drives to fail. The Recovery Guru Details area provides specific information you will need as you follow the recovery steps.
file:///D:/caution_help.gif
Caution
Electrostatic discharge can damage sensitive components. Use a grounding wrist strap or other anti-static precautions before removing or handling components.
Important Notes

• If the logical drive is marked failed because you replaced the wrong drive during a degraded logical drive recovery procedure, you have not lost data. To return the logical drive to the degraded state, reinsert the drive.
  
• You may be able to recover data from a failed logical drive. Whether or not this is possible depends on how the failure occurred. You can use this procedure to restore data in two ways: attempting a data recovery or restoring data from backup media.
  
• All I/O to the affected logical drives will fail.
  
• To the operating system (OS), a failed logical drive is exactly the same as a failed non-RAID drive. Refer to the operating system documentation for any special requirements concerning failed drives and perform them where necessary.
  
• Make sure the replacement drives have a capacity equal to or greater than the failed drives you will remove in the following steps.
  
• You can replace the failed drives while other arrays in the storage subsystem are receiving I/O.

Recovery Steps
1
It may be possible to recover data from the failed logical drives. If you wish to attempt a data recovery, you must contact your technical support representative. Do not perform steps 2 - 8. Performing any recovery actions before contacting your technical support representative could jeopardize any chance of recovering data. If you prefer to recover from an existing backup or you have mistakenly removed the wrong drive while performing a degraded logical drive recovery procedure, go to step 2.
2
If you have mistakenly removed the wrong drive while performing a degraded logical drive recovery procedure, you can return the logical drive back to the degraded state by replacing the drive you removed. After the logical drives return to the degraded state, select Recheck and perform the recovery procedure listed for a degraded logical drive. You are finished with this procedure.
3
There are several different types of logical drives that can exist in an array. Use the Recovery Guru details area to determine the affected array. Then, find the array in the Logical View of the Subsystem Management Window. Use the information provided by the AMW to determine the types of logical drives on the affected array. Step through every entry in the following table and perform all procedures associated with the logical drive type combination for the affected array.
If...
Then...
One or more FlashCopy logical drives exist on the affected array
The information on the FlashCopy(s) is no longer valid and cannot be retrieved. Delete all FlashCopy logical drives associated with the affected array. You will be able to create any needed FlashCopys after this procedure has been completed.
One or more FlashCopy repository logical drives associated with FlashCopys on other arrays exist on the affected array
The information on the FlashCopy(s) is no longer valid and cannot be retrieved. Delete all FlashCopy logical drives associated with the FlashCopy repositories on the affected array. You will be able to create any needed FlashCopys after this procedure has been completed.
The mirror repository logical drives exist on the affected array
All mirror relationships associated with primary mirror logical drives on this storage subsystem are invalid.
Save the Storage Subsystem Profile before removing mirror relationships. The profile will give you a roadmap of any mirror relationships you may want to recreate after re-activating RM. You can do this by using the View>>Storage Subsystem Profile>>Save As feature in the Storage Subsystem Management window.
Perform a remove mirror relationship for all primary mirror logical drives
Deactivate the RM feature
Activate the RM feature
One or more primary logical drive mirrors exist on the affected array
You have two options to recover from this failure.
1. Remove the mirror relationship and re-establish it after the array is brought back to optimal
OR
2. If role reversal is possible, bring the array back to optimal, change the role of the primary logical drive to secondary, and return it back to primary once the synchronization has completed .
If...
Then...
You wish to use option 1.
Remove the mirror relationship and go to Step 4
You wish to use option 2.
Go to Step 4
One or more secondary logical drive mirrors exist on the affected array
The mirror relationship will returned to an optimal state once the array is brought back to optimal and the mirror has re-synchronized.
Go to Step 4.
Only standard logical drives exist on the affected array
Go to Step 4.
4
Remove all failed drives associated with this array (the fault indicator lights on the failed drives should be lit). To determine the associated drives, select one of the affected logical drives that are listed in the Recovery Guru Details area in the Subsystem Management Window. Each associated drive will have an association dot underneath it.
5
Wait 30 seconds, then insert the new drives. The fault indicator light on the replaced drives may be lit for a short time (one minute or less).
Note: Wait until the replaced drives are ready (fault indicator light off) before going to step 6.
6
If...
Then...
One or more primary logical drive mirrors exist on the affected array
Change the role of all primary logical drives to a secondary role. Wait until the synchronization is completed on all logical drives before continuing. See comment above
7
If...
Then...
A primary or secondary logical drive mirror relationship exists on the affected array
Save this procedure by selecting Save As because once you perform step 8 and the failure is fixed, you will not be able to access the information in step 9 from the Recovery Guru.
Go to Step 8.
No primary or secondary logical drive mirror relationships exist on the affected array.
Select the array in the Logical View of the Subsystem Management Window; then, select Array>>Initialize . Result: The logical drives in the array are initialized, one at a time. When initialization starts on a logical drive, the icon changes to Operation in Progress
file:///D:/configuration/images/vol_lr_operation.gif
. When initialization is completed, all logical drives in the array are Optimal
file:///D:/vol_opt.gif
.
Note: To monitor initialization progress, select the logical drive. Then, select Logical Drive>>Properties . Note that once the operation in progress has completed, the progress bar is no longer displayed in the Properties dialog.
Save this procedure by selecting Save As because once you perform step 8 and the failure is fixed, you will not be able to access the information in step 9 from the Recovery Guru.
Go to Step 8.
8
Select Recheck to rerun the Recovery Guru to ensure that the failure has been fixed.
9
If...
Then...
You deleted one or more FlashCopy logical drives or FlashCopy repositories in Step 3
If desired, create new FlashCopys to replace those deleted.
All mirror repositores were deleted because of failed mirror repository logical drives on the affected array
Activate the RM feature
If desired, create new mirror relationships to replace those deleted
You may want to save the Storage Subsystem Profile before removing mirror relationships. Refer to item 3 in Step 3 for steps used to save the Storage Subsystem Profile.
One or more primary logical drive mirrors were changed to a secondary role in Step 6
Change the role of these logical drives back to a primary role. Wait until the synchronization is completed on all logical drives before continuing.
One or more logical drives were initialized in Step 7.
Add the initialized logical drives in the affected array back to the operating system. You may need to reboot the system to see the logical drives.
Note: Do not start I/O to these logical drives until after you restore from backup.
Restore the data for the initialized logical drives from backup.
后来只有给客户重建FASTT200存储，再重建数据库了：
Oracle数据库重建步骤（8.1.7）
1、由于数据库软件没有破坏，所以不用重新安装Oracle软件。
2、计划用裸设备来建库。
准备工作
1、  明确原安装数据库的基本情况，包括数据库根目录、主目录、实例名等；
通过查看.profile得知：
PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:$HOME/bin:/usr/bin/X11:/sbin:.
export PATH

if [ -s "$MAIL" ]           # This is at Shell startup.  In normal
then echo "$MAILMSG"        # operation, the Shell checks
fi                          # periodically.


umask 022

export DISPLAY=133.43.1.58:0.0
export ORACLE_BASE=/oracle
export ORACLE_SID=yhlbas
export TMP=/oracle/temp

export ORACLE_HOME=$ORACLE_BASE/product/8.1.7
export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
export ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data
export PATH=$PATH:$ORACLE_HOME/bin:/bin:/usr/ccs/bin:/usr/lbin:/usr/bin
export LIB_PATH=$ORACLE_HOME/lib
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/network/lib

2、  明确需要建立几个库，每个库需要的表空间、以及每个库的控制文件、联机日志文件、归档日志文件、数据文件等的详细规划；
一个数据库，通过查看前数据库pfile（inityhlbas.ora）得知:
db_name = "yhlbas"instance_name = yhlbas service_names = yhlbas  control_files = ("/dev/rlv_jfvg_128_01", "/dev/rlv_jfvg_128_02", "/dev/rlv_jfvg_128_03") open_cursors = 300max_enabled_roles = 30db_block_buffers = 153600#76800 shared_pool_size =209715200 #157286400 large_pool_size = 31457280java_pool_size = 31457280 log_checkpoint_interval = 10000log_checkpoint_timeout = 180000 processes = 500#150 log_buffer = 3145728 # audit_trail = false  # if you want auditing# timed_statistics = false  # if you want timed statistics# max_dump_file_size = 10000  # limit trace file size to 5M each # Uncommenting the lines below will cause automatic archiving if archiving has# been enabled using ALTER DATABASE ARCHIVELOG.log_archive_start = truelog_archive_dest_1 = "location=/arch2 reopen=600"log_archive_format = arch_%t_%s.arc  #DBCA uses the default database value (30) for max_rollback_segments#100 rollback segments (or more) may be required in the future#Uncomment the following entry when additional rollback segments are created and made online#max_rollback_segments = 151# If using private rollback segments, place lines of the following# form in each of your instance-specific init.ora files:rollback_segments = ( RBS0, RBS1, RBS2, RBS3, RBS4, RBS5, RBS6, RBS7, RBS8, RBS9, RBS10, RBS11, RBS12, RBS13, RBS14, RBS15, RBS16, RBS17, RBS18, RBS19, RBS20, RBS21, RBS22, RBS23, RBS24, RBS25, RBS26, RBS27, RBS28 ) # Global Naming -- enforce that a dblink has same name as the db it connects to# global_names = false # Uncomment the following line if you wish to enable the Oracle Trace product# to trace server activity.  This enables scheduling of server collections# from the Oracle Enterprise Manager Console.# Also, if the oracle_trace_collection_name parameter is non-null,# every session will write to the named collection, as well as enabling you# to schedule future collections from the console.# oracle_trace_enable = true # define directories to store trace and alert filesbackground_dump_dest = /oracle/admin/yhlbas/bdumpcore_dump_dest = /oracle/admin/yhlbas/cdump#Uncomment this parameter to enable resource management for your database.#The SYSTEM_PLAN is provided by default with the database.#Change the plan name if you have created your own resource plan.# resource_manager_plan = system_planuser_dump_dest = /oracle/admin/yhlbas/udump db_block_size = 8192 remote_login_passwordfile = exclusive os_authent_prefix = "" compatible = "8.1.0"sort_area_size = 1048576sort_area_retained_size = 1048576 #20060324 by olmdb_file_multiblock_read_count=64
3、备份原数据库的口令文件、参数文件、.profile文件；
4、搭建硬件物理环境，准备相应的裸设备载体，并设置好这些设备的宿主及权限。
准备物理环境
1、  关闭FastT200存储；
2、  换上坏掉的硬盘及控制器电池；
3、  开启FastT200存储；
4、  进入管理软件，查看硬盘及控制器电池状态，并重设控制器电池日期；待一切正常（物理硬件）后，用串口登录存储。
5、  在每个控制器上运行sysWipe命令，清楚所有的原始设置。
6、  重启fastt200存储，再次用串口登录到每一个控制器，用netCfgSet命令设置每一个串口的IP信息，将其设置到小机一个网段，这样便于管理。
7、  登录到管理软件，对存储进行创建创建逻辑驱动器、创建RAID、创建逻辑磁盘、定义主机、定义主机端口等操作。
以下操作大致如：
(1)    把FastT200的两块控制卡的网络接口和安装有SM9的管理机连接在同一个交换机上
(2)    在SM管理界面增加设备,输入FastT200控制卡的IP地址（亦可以自动被识别）

(3)    创建逻辑驱动器
打开向导
选择RAID级别及硬盘


选择创建逻辑盘的大小及LUN号
创建完成,可继续创建新逻辑盘

(4)    定义主机
输入主机名

(5)    定义主机端口
选择光纤通道卡的串号


输入主机类型及主机端口名字
(6)    完成

小机部分处理：
1、  Export原来的卷组jfvg（在这之前如果jfvg为活动的，varyoffvg jfvg）；
2、  删除原来的从存储上识别的磁盘；
rmdev  -dl hdisk3
rmdev  -dl hdisk4
rmdev  -dl hdisk5
rmdev  -dl hdisk6
rmdev  -dl hdisk7
rmdev  -dl hdisk8
rmdev  -dl hdisk9
rmdev  -dl hdisk10
rmdev  -dl hdisk11
rmdev  -dl hdisk12
rmdev  -dl hdisk13
rmdev  -dl hdisk14
rmdev  -dl hdisk15
rmdev  -dl hdisk16
rmdev  -dl hdisk17
rmdev  -dl hdisk18
rmdev  -dl hdisk19
rmdev  -dl hdisk20
rmdev  -dl hdisk21
rmdev  -dl hdisk22
rmdev  -dl hdisk23
rmdev  -dl hdisk24
rmdev  -dl hdisk25
rmdev  -dl hdisk26
rmdev  -dl hdisk27
rmdev  -dl hdisk28
rmdev  -dl hdisk29
rmdev  -dl hdisk30
rmdev  -dl hdisk31
rmdev  -dl hdisk32
rmdev  -dl hdisk33
rmdev  -dl hdisk34
rmdev  -dl hdisk35

3、  重认从存储划过来的盘：cfgmgr –v
以上3个步骤在主备机上都要执行，下面步骤仅在主机上执行即可。
4、  创建卷组jfvg（将卷组的PP设置成128MB）
5、  创建裸设备（先暂时创建这么多，以后根据需要可以再建）：
mklv –y lv_jfvg_512_01 –t raw jfvg 4
mklv –y lv_jfvg_512_02 –t raw jfvg 4
mklv –y lv_jfvg_512_03 –t raw jfvg 4
mklv –y lv_jfvg_512_04 –t raw jfvg 4
mklv –y lv_jfvg_512_05 –t raw jfvg 4
mklv –y lv_jfvg_512_06 –t raw jfvg 4
mklv –y lv_jfvg_512_07 –t raw jfvg 4
（以上7个文件作为数据库创建后系统用的表空间数据文件的补充）
mklv –y lv_jfvg_512_08 –t raw jfvg 4
mklv –y lv_jfvg_512_09 –t raw jfvg 4
mklv –y lv_jfvg_512_10 –t raw jfvg 4
mklv –y lv_jfvg_512_11 –t raw jfvg 4
mklv –y lv_jfvg_512_12 –t raw jfvg 4
mklv –y lv_jfvg_512_13 –t raw jfvg 4
mklv –y lv_jfvg_512_14 –t raw jfvg 4
（以上文件可以作为数据库临时表空间，回退表空间等的补充）
mklv –y lv_jfvg_2048_01 –t raw jfvg 16
mklv –y lv_jfvg_2048_02 –t raw jfvg 16
mklv –y lv_jfvg_2048_03 –t raw jfvg 16
mklv –y lv_jfvg_2048_04 –t raw jfvg 16
mklv –y lv_jfvg_2048_05 –t raw jfvg 16
mklv –y lv_jfvg_2048_06 –t raw jfvg 16
mklv –y lv_jfvg_2048_07 –t raw jfvg 16
mklv –y lv_jfvg_2048_08 –t raw jfvg 16
mklv –y lv_jfvg_2048_09 –t raw jfvg 16
mklv –y lv_jfvg_2048_10 –t raw jfvg 16
（以上作为表空间的数据文件）
6、  更改这些设备的宿主：
chown oracle:dba /dev/*lv_jfvg_*
7、  更改这些设备的权限（这里将其赋予最大权限）：
chmod 777 /dev/*lv_jfvg_*
8、在jfvg上创建一个/oracle2文件系统，用来存放创建数据库用的控制文件，系统用表空间数据文件等，并且用chown命令更改文件系统权限，使得oracle用户有权限读写。

建库实施步骤
在这之前，备份好.profile和inityhlbas.ora文件以及口令文件和监听文件
1、  删除原有的数据库（dbassist工具），如果因为原数据库不能启动到mount状态执行以下过程来通过删除原实例来实现：
删除元数据库的数据文件、log文件、控制文件、dump文件、参数文件及密码文件；
删除系统中的oratab文件（此文件具体位置不好说，可以用find命令进行查找）中记录原来实例的那一行。
2、  建立相应的裸设备及设置好他们的宿主和权限（前面已经实现）；
3、  建库：
用dbassist工具：
进入configuration assistant窗口，选择create database：



选择建库的方式，这里选择自定义方式建库：




选择要建立的数据库的类型，这里选择Multipurpose：


确定要并发访问数据库的最大用户量，根据实际情况而定：




确定数据库采用哪种模式，是专有模式还是共享模式，这里我选择专有模式（第一项）：

选择在数据库中我们想要去配置的选项（通常情况下选择最后一个就行了）：





输入数据库名称，实例名，pfile路径还有设置字符类型，这里的数据库名称按客户要求来填，但是实例名必须要和环境变量中指定的实例名一致：

输入控制文件的载体以及设置相关的参数：




这里设置系统表空间、tools表空间、user表空间……的大小以及相应的数据文件和相关参数
指定联机日志文件及相关参数：



设置checkpoint interal等参数，一般默认就好；另外决定是否开启归档，并指定归档日志的格式及目标地址。

这里默认就好：





设置共享池等的值：（这里可按照原来的数据库的值取值）：





设置TRACEfile（跟踪文件）目录：一般情况下默认就好：


点击Create database now，完成库的创建：

以上建库步骤是在主机上执行，下面进行备机的数据库配置以实现oracle双机
由于，在主机上创建数据库的时候，将控制文件、联机日志文件、表空间数据文件都放在存储上，所以，根据主机参数文件的相关信息和参考主机oracle配置，将主机上相关的参数文件、口令文件、跟踪文件、监听文件等拷贝到备机相应的目录即可：
1、  停掉主机oracle应用，并vayoffvg jfvg；
2、  在备机上导入卷组jfvg：importvg –y jfvg hdiskname （hdiskname是从存储上识别的磁盘并且在主机上划入了jfvg）；
3、  从主机上拷贝相应的文件到备机，覆盖备机上原来的文件。
4、  启动数据库。
这里，如果启动数据库报错，查看alertlog获取报错的原因，在根据具体情况进行更改即可。注意参考主机的oracle配置情况就是了。
5、  在备机的数据库启动一切正常后，停掉oracle数据库应用。
6、  进行双机调试，这里，因为原ha配置并没有破坏，而且后来创建的jfvg和原来的是一样的，也就是说重建后的所有卷组、网络等都没有发生改变，所以，双机配置不需要进行更改。在主备机资源同步后，启动双机查看状态是否正常，oracle数据库是否正常启动。如果在此步骤中发生异常，更根据错误日志，进行相应的更改即可，知道调试正常。
Oracle用户、表空间等的创建以及性能调优
这里，我用oracle client（客户端软件）图形工具来进行：
所以，在这之前就要做如下准备工作：
1、配置好oracle主机网络如：监听程序、网络服务名、命名方法等。又由于，我们重建的数据库的实例名、数据库名、IP地址、数据库模式等都没有发生改变，所以，这里我们只需要将原监听文件、tnsnames.ora等文件恢复到原数据库的状态即可（在前面的步骤已备份原数据库的这些文件），当然也可以手工编辑这些文件，同样也可以通过netmgr图形软件（8.1.7没有此功能）实现配置。
2、启动监听程序：用oracle用户进入命令行，用lsnrctl start命令来启动监听程序。
3、配置客户端网络，可以利用oracle客户端的网络配置工具进行配置，在配置的时候，注意监听端口等的配置要和主机的配置一致。
4、启动客户端软件，登录到数据库。此时，利用该软件就可以进行数据库用户的创建、表空间的创建以及数据库性能的调优工作：
下面以裸设备来创建lbas01表空间为例进行介绍：
在/oracle目录下创建links目录，然后在其目录下创建裸设备rlv_jfvg_2048_01到该目录下lbas01_01的链接，然后利用客户端工具进行创建表空间如下图：

Oracle数据库备份
首先应该提到的是，不论采用哪种方式进行备份，都应该遵循以下规则：
遵守备份恢复的黄金法则（包含冗余集的磁盘或其它介质应该不在包含数据文件、联机日志和控制文件的硬盘上）
选择数据库归档模式
多工控制文件、联机日志和归档日志
经常定期地实施备份
改变结构时实施备份
备份经常使用的表空间
在不可恢复/不记录的操作之后实施备份
在以RESETLOGS选项打开数据库后，实施整个数据库备份
归档较老的备份
了解分布式数据库备份的限制
为了附加的保护和灵活性引出数据
避免联机重复日志的备份

备份类型：执行用户管理的备份
根据数据库运行的状态（ARCHIVELOG或NOARCHIVELOG）进行用户管理的备份也分为两种情况：
一、当数据库运行在ARCHIVELOG（归档）模式下可以采用如下步骤进行备份：
1、  是备份的表空间处在备份模式，使用如下命令：
ALTER TABLESPACE  ‘表空间名’  BEGIN BACKUP;
2、  使用操作系统命令把要备份的表空间的数据文件复制到指定的路径：
如：dd if=/dev/rlv_jfvg_2048_01  of=/backup/rlv_2048_01bk  
3、  结束表空间的备份：
ALTER TABLESPACE ‘表空间名’ END BACKUP;
4、  归档联机日志文件：
ALTER SYSTEM ARCHIVE LOG CURRENT;
二、当数据库运行在NOARCHIVELOG（非归档）模式下可以采用如下步骤进行备份：
1、  以SYSDBA身份登录数据库
2、  干净的关闭数据库：SHUTDOWN IMMEDIATE或SHUTDOWN NORMAL或SHUTDOWN TRANSACTIONAL
3、  使用操作系统命令备份数据库：使用操作系统命令把控制文件、数据文件、SPFILE等文件复制到一个指定的磁盘(对于裸设备文件用dd命令进行备份，对于文件系统文件采用cp命令)
如：dd if=/dev/rlv_jfvg_128_01 of=/backup/rlv_jfvg_128_01bk
    cp $ORACLE_HOME/dbs/inityhlbas.ora   /backup/dbs
4、  重新启动数据库。
结合以上，建议用户在备份的时候，最好在可以停掉数据库的时候采用“一”的方式进行备份，另外同时将参数文件（inityhlbas.ora）、.profile（oracle用户）文件及口令文件（orapwyhlbas）进行备份。

备份的补充：使用输出（exp）的补充保护
使用Export（输出）实用程序，把数据移出数据库。
Export把来自oracle数据库的数据以二进制格式写到操纵系统文件中。Import读取Export文件，并在现有的数据库中重建相应的信息。虽然Export和Import是为移动oracle数据库设计的，但是用户也可以用来对数据库备份进行补充。
使用Export
注意：使用export来备份的时候，用户必须以逻辑上一致的方式输出所有数据，从而使备份反映时间上的单个点。在Export操作进行时，任何人都不能对数据库进行任何改变。所以，理想情况是，用户应该在输出数据时，在限制模式（restricted mode）下运行数据库（如果数据库处于关闭状态则执行STARTUP RESTRICT；如果数据库处于OPEN状态，则执行ALTER SYSTEM enable restricted session；让数据库处于限制模式），此时，通常用户不能访问数据。
另：在执行Export前，需要运行SQL脚本catexp.sql或catalog.sql。这些脚本只运行一次。这些脚本用来创建导出需要的数据字典，创建角色EXP_FULL_DATABASE,给角色EXP_FULL_DATABASE赋予必要的权限等。
   为了执行导出操作，用户必须要有CREATE SESSION的系统权限；为了导出其他用户模式下的表，用户必须被授予EXP_FULL_DATABASE权限。
以下以使用参数文件执行全库导出为例：
1、  用oracle进入操作系统命令行
2、  创建导出参数文件；vi expFILE （expFILE是本例中参数文件的名字）：参数文件内容大致如下：
FILE=fulldata
GRANTS=y
FULL=y
ROWS=y
………………
其中，FULL=y是执行全库导出必须的；FILE=fulldata指定导出文件的路径以及名字；GRANTS=y表示要导出授权；ROWS=y表示不仅要导出表的结构，还要导出数据。
3、  执行全库导出：
exp  SYSTEM/password  PARFILE=expFILE （其中expFILE就是2中创建的参数文件）。



文件:
Oracle数据库(8.1.7)重建步骤.rar
大小:
1954KB
下载:
下载

文件:
FastT200 ERROR.rar
大小:
3KB
下载:
下载


这里传上文档附件，希望大家不吝赐教！




本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/109220/showart_2136028.html