摘自《IBM AIX 从入门到精通》 1、物理区域分区     如要添加一个硬盘到系统中，AIX操作系统将这块硬盘配置为物理卷，并且给该物理卷生成一个PVID标识，可以通过chdev命令更改物理卷生成PVID。     在逻辑上，逻辑卷存在于卷组中，在物理上，它存在于物理卷上。 2、物理卷属性显示     在AIX中，如将硬盘配置为逻辑卷，则需要查看物理卷的属性。若要显示物理卷的属性，则需运行lspv命令。 （1）显示pv属性：lspv -L （2）显示物理卷中逻辑卷状态：lspv -l （3）显示物理卷与逻辑卷对应状态：lspv -M （4）显示物理分区状态：lspv -p 3、物理卷属性更改     使用chpv命令 4、物理卷数据迁移     使用migratepv命令

太阳晒在身上暖暖的，很久没写点什么了。 前段时间接触到一个需求，把IDC机房小型机迁移到虚拟化平台上。 大家商量着觉得难点有以下几个 AIX系统上的业务系统如何迁移到X86的PC服务器上 数据库的迁移 PC服务器如何配置才能和小型机性能接近，也就是说什么配置能满足到业务系统的稳定工作。 前2个问题大家有好的资料可以回复 先分析下第3个难点，目前主流的测试方法SAP S&D 2 –Tier（用户数/核）值分析， TPMC(计算机事务处理能力）值分析等方法，以下为分析表格。        数据来源：http://www.sap.com/solutions/benchmark/index.epx ，据说用了虚拟PC服务器。     虽然SAP S&D 2 –Tier与TPCC值分析有一定的差距，不过可以往高比例配置，这样有一定的性能冗余。 本文转自 tim2009 51CTO博客，原文链接：http://blog.51cto.com/virtualbox/782210，如需转载请自行联系原作者

ORACLE 11G 新部署的环境，刚使用GOLDENGATE 进行完数据迁移和同步，发现ORACLE 自动收集的任务时间　　并不是设定的晚上22点启动。检查AIX 时区发现设置的CDT ，数据库的TIMEZONE 是CST6CDT，与系统管理　　员沟通，他答复是AIX 6.1 没有北京时间这个时区了，所以没有按照手册特别设置，现在只能进行时区更改为　　Asia/Shanghai，OS更改完成后GOLDENGATE / ORACLE /AIX 全部重启。　　问题接踵而至　　1.GOLDENGATE 所有的TRAIL FILE 时间都被更改导致REPLICATE ABEND　　解决方法：　　ALTER REPLICAT REP* , extseqno xxx ,extrba xxx　　2.ORACLE 中发现数据库的TIMEZONE 还需是原来的，统计信息自动收集任务时间还是异常　　解决方法：　　数据库时区更改参考：http://space.itpub.net/175005/viewspace-618100　　确认业务表没有使用TIMESTAMP WITH LOCAL TIME ZONE 类型的　　ALTER DATABASE SET TIME_ZONE='+08:00';　　Completed: ALTER DATABASE SET TIME_ZONE='+08:00'　　Wed Oct 09 09:37:10 2013　　重启数据库　　检查更改是否成功　`javascriptselect * from database_properties where property_name = 'DBTIMEZONE'; 　　检查 scheduler default_timezone 的设置 9:40:01 SQL> set verify off9:40:08 SQL> variable v_value varchar2(1000);9:40:20 SQL> begin2 dbms_scheduler.get_scheduler_attribute(attribute => 'default_timezone',value => :v_value);3 end;4 /PL/SQL procedure successfully completedExecuted in 0.016 seconds v_value CST6CDT 发现依然是更改前的TZ CST6CDT 进行更改： 9:44:12 SQL> BEGIN2 DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE(3 ATTRIBUTE => 'default_timezone',4 VALUE => 'Asia/Shanghai');5 END;67 /PL/SQL procedure successfully completedExecuted in 0.031 seconds 　　一个小问题折腾了半天。 最新内容请见作者的GitHub页：http://qaseven.github.io/

    即使大部分的企业都已经在他们的物理服务器中采用了虚拟化技术，第三方软件和服务提供商Transplace仍然打算更进一步，这家公司号称其95%的服务器、存储和灾难恢复系统都已经实现了虚拟化。 你总是会在许多场合听到：虚拟化在非关键业务系统中是解决成本的最好办法，但还没有为在生产流程中运行应用做好准备。 无论如何，Transplace首席技术官Vincent Biddlecombe可不这么认为。Transplace是一家以SaaS形式向用户提供逻辑软件的公司，共有大约500名员工，每年销售额在25亿美元左右。 大概不到一年前，Transplace公司决定进行数据中心的迁移，他们他们就决定将位于德州普莱诺的办公大楼十层的数据中心迁移到一个更安全的地点。在考虑各种选择的时候，他们曾设想过很多可能性，例如将所有应用扩管外包或者对内部架构进行全面翻新。“很明显我们继续自己托管自己的应用要比我们去外包更有成本效率。”Biddlecombe表示。 成本计算是虚拟化技术的一个重要部分，“偶然间，就在我们要将我们的主数据中心迁移到一个托管机房数据中心的时候，正好遇到我们准备进行服务器的硬件升级，因此，这让我们可以以最干净的方式开始进行虚拟化。” 在其后的8个月里，Tran成功地将他们的数据中心从普莱诺迁移到了达拉斯，并且将IT基础架构从物理状态转变成为虚拟状态。在这个进程进行中，Transplace公司节省了大量的在软件许可证方面的开支，同时服务器的数量也减少了;Transplace公司还能够按照需要增加存储容量，加强位于洛厄尔的灾难恢复站点的灾难恢复功能，最终使IT部门能够将更多的精力用于关键业务项目上。 Transplace公司提供定制化的内嵌于Java中的逻辑软件，其是在BEA WebLogic中运行的。在数据库方面，Transplace的选择是Oracle，Oracle方面，Biddlecombe将数据库从Sun硬件迁移到运行AIX系统的IBM 570服务器上，Biddlecombe在将底层运行Solaris的Sun服务器转变成为运行VMware ESX Server虚拟化软件的64位操作系统服务器的时候并没有遇到什么问题。这样一来，传输速度提升了两倍之多。Transplace将他们大多数的物理服务器转变成虚拟机，只是Biddlecombe并没有给出一个具体的数目。 为了管理存储，Transplace将所有虚拟服务器迁移到NetApp存储系统中，采用NetApp的SnapMirror软件来保持普莱诺数据中心和洛厄尔灾难恢复站点之间的数据同步。 “所有的都复制了——我们所有的数据和服务器，都在两个站点之间进行了复制和备份。同时，我们还使用这个灾难恢复站点进行应用和环境测试，我不再需要管理100台物理服务器了。”Biddlecombe表示。 为了自动的进行两个站点间的备份，Transplace安装了VMware的vCenter Site Recovery Manager。Biddlecombe表示：“vCenter可以自动识别数据中心内哪些服务器是活动的，这些服务器怎样被映射在灾难恢复站点中。所有这些构成了整个备援流程。” 迁移TB级别的数据(Transplace公司仅仅是每台服务器的根目录就有30GB，总共加起来有3TB)、维持两个站点间的完全同步，占用了很大一部分的带宽和存储空间。为了将此存储的需求，Bidd使用了重复数据删除技术软件将存储效率提高了65%。而在带宽整合方面，Biddlecombe选择SilverPeak的NX设备实现了两个数据中心的数据吞吐量优化。 最后的结果很令人满意，Transplace获得了应用性能的提升和存储容量快速配置，“如果我们需要更多的计算能力，我们增加一台虚拟服务器就可以，如果我们需要测试一个应用，那么就创建一个新的环境。”Biddlecombe表示，如果遇到灾难，那么Transplace就会启动备援流程到他们位于洛厄尔的数据中心，而且不会造成业务的中断。“在此之前，我们的存储系统日益脆弱，而现在我们有了更多的空间和灵活性，当你花费更少的时间来管理系统的话，就会有更多的时间重点放在改善企业业务上。”   作者：FOXL 来源：51CTO

详见红色字体部分，估计是EBS中一些特殊的object不适用这种方式，普通数据库可以采用。所以目前EBS还只能是传统的XTTS (跨平台传输表空间) 及 EXPDP/IMPDP+OGG两种方法 。  Known Issues and Limitations of XTTS     Built-in Limitations  Built-in limitations are documented in the Oracle Database Administrator's Guide, 11g Release 2 (11.2). One important limitation outlined in this document that is relevant for EBS is that the source and target databases must have the same character set and national character set. Column Encryption Using TDE  Transportable Tablespaces migration is not supported for tables that have columns encrypted using the Transparent Data Encryption (TDE) functionality of Oracle Database 11g (see My Oracle Support Document 732764.1). Tables that have encrypted columns must be de-crypted prior to following the transportable tablespaces migration and then encrypted in the target database after migration. Mixing RDBMS and EBS Schemas in the same Tablespace  The use of RDBMS and EBS Schemas in the same tablespace is not supported as tablespaces with RDBMS schemas are disregarded in the creation of the transportable set. It is recommended that RDBMS schemas (such as CTXSYS) be in separate tablespaces (for example, SYSAUX). Cross Platform Incremental Backup (跨平台增量备份方式) Cross Platform Incremental Backup is not certified to work with an EBS database. 参考Oracle文档 ：  Using Transportable Tablespaces for EBS Release 12.0 or 12.1 Using Database 11gR2 (文档 ID 1311487.1)   本文转自ITPUB博客tolywang的博客，原文链接：EBS R12的11g库从AIX迁移到Linux不能采用 Cross Platform Incremental Backup 的原因，如需转载请自行联系原博主。

关于跨OS 的DB 迁移，MOS 上有相关的文章说明：[ID733205.1]。 　　To migrate anexisting Oracle database (NOT BINARIES)  from one Operating Systemplatform to another (i.e. Windows to Solaris) ,This can occur as part ofan Oracle version upgrade (Oracle 8i .. Oracle 11G) or within the sameOracle version: (Oracle 10.2 to Oracle 10.2). 　　--可以将Oracle DB 从一个操作系统迁移到另一个操作系统，比如从windows到Solaris，注意这里的迁移仅仅是数据的迁移，不包含DB 的安装介质。这个迁移可以是不同DB版本的迁移，比如从8i 到11g，也可以是相同版本的迁移，比如从10.2 到10.2. 　　Changes withinan Operating System (ie: Linux,Windows or Solaris from 32 bit to 64 bit) arenot considered cross platform migrations and are performed as normal versionupgrades/wordsize conversions. 　　--改变操作系统不用考虑系统的平台，可以按照正常的db version upgrades 和 wordsize 的改变来操作。 　　一. 解决方法 　　There is no migrationutility (Script or DBUA) to perform a cross platform migration of an OracleDatabase. 　　--没有迁移工具如脚本或者DBUA来执行跨OS的数据迁移。 　　Changingplatforms requires the database be re-built and / or the data moved using oneof the following methods: 　　--跨平台的迁移需要重建数据库，然后使用如下的一种方法来完成数据的迁移工作。 　　(1)    Export / Import to include theuse of Datapump facilities. All versions support Export/Import but for Datapump10.1.0.2 or higher is required 　　(2)    Transportable Tablespaces 10Gor Later 　　(3)    RMAN Convert Databasefunctions. 10G or Later 　　(4)    Streams Replication 　　(5)    Create Table As Select (CTAS) 　　(6)    Dataguard Heterogeneous Primaryand Physical Standbys 　　(7)    Oracle Golden Gate 　　Each availablechoice will have strengths and limitations to include data types, time requiredand potential costs. 　　--每一个可选的方法都有它的优势和限制，如数据类型，需要的时间和一些潜在的消耗。 　　The choicesavailable will depend on BOTH the Operating System and Oracle versions on boththe source and destination. 　　--方法是否可用也取决与Source 和 Destination 两端的操作系统和Oracle版本。 　　二. 示例 　　There areplatform limitations when using Dataguard Heterogeneous Primary and PhysicalStandbys。 　　--比如使用DG的异构平台来迁移时，就会有操作系统的限制。 关于这块内容，之前有详细的Blog： 　　Oracle DataGuard 支持的异构平台 说明 　　http://blog.csdn.net/tianlesoftware/article/details/7241488 　　RMAN ConvertDatabase only works if both source and destination belong to the same ENDIANformat. 　　--RMAN Convert DB 仅在source 和destination 的ENDIAN 格式相同的情况下才可以使用。 　　RMAN's convertfunction for Transportable Tablespaces will convert from one ENDIAN format toanother. 　　在ENDIAN 格式不同的情况下，可以使用RMAN convert function 来转换ENDIAN 从一种格式到另一种格式。如： 　　RMAN> convert tablespace TBS1 to platform="Linux IA(32-bit)" FORMAT '/tmp/%U'; 　　两端相同之后，就可以进行Transportabletablespace 的操作。 　　可以通过v$transportable_platform视图查看系统的ENDIAN 格式： SQL> columnplatform_name format a35 SQL> select *from v$transportable_platform order by 1; PLATFORM_IDPLATFORM_NAME                      ENDIAN_FORMAT ---------------------------------------------- -------------- 1 Solaris[tm] OE (32-bit)             Big 2 Solaris[tm] OE (64-bit)             Big 3 HP-UX (64-bit)                      Big 4 HP-UX IA (64-bit)                   Big 5 HP Tru64 UNIX                       Little 6 AIX-Based Systems (64-bit)          Big 7 Microsoft Windows IA (32-bit)       Little 8 Microsoft Windows IA (64-bit)       Little 9 IBM zSeries Based Linux             Big 10 Linux IA (32-bit)                   Little 11 Linux IA (64-bit)                   Little 12 Microsoft Windows x86 64-bit        Little 13 Linux x86 64-bit                    Little 15 HP Open VMS                         Little 16 Apple Mac OS                        Big 17 Solaris Operating System (x86)      Little 18 IBM Power Based Linux               Big 19 HP IA Open VMS                      Little 20 Solaris Operating System(x86-64)   Little 21 Apple Mac OS (x86-64)               Little 20 rowsselected.     最新内容请见作者的GitHub页：http://qaseven.github.io/   

跨平台跨版本迁移方案对比 针对跨平台跨版本的迁移，主要有以下三种方式：数据泵、GoldenGate / DSG、XTTS，针对停机时间、复杂度、实施准备时间，做了以下列表比对： 客户的需求都是最短停机时间，最少数据丢失。对于 GoldenGate / DSG 来说它的停机时间是最短的，但实施准备时间最长，复杂度最高；数据泵是停机时间最长，实施准备时间最短；XTTS 是介于这两者之间的，同时满足客户提出的短停机时间、低实施成本需求。 数据泵比较适用的场景就是数据量比较小、数据大概在 5T 以下，使用数据泵会方便很多。 GoldenGate / DSG 比较适用大数据量的数据分发，灾备库建设。 XTTS 是单次数据库跨平台、跨版本迁移利器，相同平台，相同版本迁移首选 rman。 在 Oracle11g 中的 RMAN 支持不同操作系统和不同 DB 版本之间的使用，关于 RMAN 的兼容性。如下图示： 注意以下操作系统的组合，这里假设 DB version 相同： （1）For Oracle Database 10g Release 2 and above releases: --在 Oracle 10gR2 之后的版本，支持如下操作系统之间的 RMAN 操作： Solaris x86-64 <-> Linux x86-64 HP-PA <-> HP-IA Windows IA (64-bit) / Windows (64-bitItanium) <-> Windows 64-bit for AMD / Windows (x86-64) （2）For Oracle Database 11g Release 1 and above releases (requires minimum 11.1 compatible setting): --在 Oracle 11gR1 之后的版本，支持如下操作系统之间的 RMAN 操作，当然这里也包含第一条里提到的 10gR2 后的组合。 Linux <-> Windows （3）For Oracle Database 11g Release 2(11.2.0.2) and above releases: Solaris SPARC (64-bit) <-> AIX(64-bit) - Note: this platform combination is currently not supported due to Bug 12702521 --在 11gR2 中，因为 Bug 12702521 的存在，Solaris SPARC (64-bit) <-> AIX (64-bit) 这2个版本之间不能进行 RMAN 操作。 XTTS 同样须遵循 Oracle 升级路线： Oracle 9i/10g/11g 数据库升级路线图（upgrade roadmap） 2XTTS 各版本功能对比 XTTS (Cross Platform Transportable Tablespaces) 跨平台迁移表空间，是 Oracle 自10g 推出的一个用来移动单个表空间数据以及创建一个完整的数据库从一个平台移动到另一个平台的迁移备份方法。它是 Oracle 8i 开始就引入的一种基于表空间传输的物理迁移方法，命名为 TTS，不过 8i 的表空间迁移仅支持相同平台、相同块大小之间的表空间传输，从 Oracle 9i 开始，TTS 开始支持同平台中，不同块大小的表空间传输，这个时候很多数据库管理员就注意到了 TTS 在实际工作中的应用，不过由于每次移动表空间都需要停机、停业务，而 9i 的 TTS 只能在相同平台之间进行数据移动，相比 Oracle RMAN 本身的快捷方便，更多人更愿意选择使用 RMAN 进行数据备份、数据移动，基于 TTS 的这些缺点，Oracle 10g 时代引入了跨平台的表空间传输方案 XTTS，标志着第一代 XTTS 的诞生。 可以理解为 TTS 就是传输表空间，把表空间传输出去，数据从一个库传输到另外一个库，不支持增量备份，而 XTTS 是在 TTS 基础上做了一些更新，支持了跨平台，支持增量备份。 XTTS 各版本的功能比对如下，表一：XTTS 各版本功能比对表 在 Oracle11gR2（推荐使用 11.2.0.4 及之后版本）以后，Oracle 推出了通过前滚数据文件，拷贝数据后再进行多次增量备份的 XTTS 来完成迁移过程，在这个过程中通过开启块跟踪特性，根据 SCN 号来执行一系列的增量备份，并且通过对块跟踪文件的扫描，来完成增量数据的增量备份应用，最后在通过一定的停机时间，在源库 read only 的状态下进行最后一次增量备份转换应用，使得整个迁移过程的停机时间同源库数据块的变化率成正比。这样大大的缩短了停机时间。 3XTTS 前置条件检查 使用 XTTS 进行数据迁移需要具备的哪些前置条件？ 可列出如下表格进行详细对比： 说明： 如果源端空间不够可以采用 NFS 磁盘挂载的方式，即将 Linux 的 NFS 文件系统挂载到中间环境（AIX 小机）的方式。XTTS 基于 RMAN 备份的方法，对于空间需求要求较高。目标端新环境，提前安装并部署好 Oracle+ASM 环境，同时创建与现有生产库字符集一致的数据库。4XTTS 三种迁移方式 采用 XTTS 迁移方式，具备跨平台字序转换和全量初始化加增量 merge 的功能，非常适用于异构 OS 跨平台迁移，成为数据库实施人员中公认的大数据量跨平台迁移的最佳选择。 传统的 TTS 传输表空间要求数据由源端到目标端传输的整个过程中，表空间必须置于 read only 模式，严重影响业务可用性。XTTS 方式可以在业务正常运行的情况下，进行物理全量初始化，增量 block 备份，数据高低字节序转码，增量 block 应用，保持目标端与源端数据的同步，整个过程不影响源端数据库使用。在最后的增量 block 应用完毕后，利用停机窗口进行数据库切换，显著地减少了停机时间。 XTTS 技术主要通过 DBMS_FILE_TRANSFER、RMAN 备份、手工 XTTS 迁移三种方式来进行数据库迁移： 4.1 方式一：dbms_file_transfer DBMS_FILE_TRANSFER 包是 Oracle 提供的一个用于复制二进制数据库文件或在数据库之间传输二进制文件的程序包，在 XTTS 迁移中，利用不同的参数进行数据文件传输转换完成迁移。 DBMS_FILE_TRANSFER 方式主要使用了 xttdriver.pl 脚本的以下几个参数： 4.2 方式二：RMAN Backup RMAN Backup 方式是基于 RMAN 备份原理，通过使用 rman-xttconvert_2.0 包提供的参数，对数据库进行基于表空间的备份，将备份生产的备份集写到本地或者 NFS 盘上，然后在通过 rman-xttconvert_2.0 包中包含的不同平台之间数据文件格式转换的包对进行数据文件格式转换，最后通过记录的表空间 的FILE_ID 号与生产元数据的导入来完成。 RMAN Backup 方式主要使用了 xttdriver.pl 脚本的以下几个参数： 4.3 方式三：手工 XTTS 迁移 Oracle 提供的封装 perl 脚本仅支持目标系统 LINUX，而通过手工 XTTS 迁移的方式可以支持目标系统是 AIX、HP、SOLARIS 等 UNIX 系统，主要有如下几个阶段： 1）rman copy rman target / <<eof run{ allocate channel c1 type disk; allocate channel c2 type disk; backup as copy datafile 18,19,20,21,22........ format '/dump1/enmo/copy/enmo_%U'; release channel c1; release channel c2; } EOF </eof 2） 数据文件格式转换 convert from platform 'HP-UX IA (64-bit)' datafile '/dump1/ccm/vvstart_tabs.dbf' format '+FLASHDATA/ORCL/DATAFILE/vvstart_new_01.dbf'; 3） 增量备份 set until scn=1850 backup incremental from scn 1000 datafile 18,19,20,21,22...... format '/dump1/enmo/incr/copy_%d_%T_%U';3; 4） 增量转换和应用 增量转换： sys.dbms_backup_restore.backupBackupPiece(bpname => '/dump1/enmo/incr/copy_ORCL_20160707_78ra40o7_1_1', fname => '/dump1/enmo/incr/copy_ORCL_20160707_78ra40o7_1_1_conv',handle => handle,media=> media, comment=> comment, concur=> concur,recid=> recid,stamp => stamp, check_logical => FALSE,copyno=> 1, deffmt=> 0, copy_recid=> 0,copy_stamp => 0,npieces=> 1,dest=> 0,pltfrmfr=> 4); 增量应用： sys.dbms_backup_restore.restoreBackupPiece(done => done, params => null, outhandle => outhandle,outtag => outtag, failover => failover); 三种方式的目标端数据库版本均需要为 11.2.0.4 版本或者以上，如果在使用过程中，目标库的版本是 11.2.0.3 或者更低，那么需要创建一个单独的 11.2.0.4 版本数据库作为中间库来在目标端进行数据文件的格式转换，而使用 DBMS_FILE_TRANSFER 包目标端的数据库版本必须是 11.2.0.4。 5XTTS 初始参数说明 XTTS 是基于一组 rman-xttconvert_2.0 的脚本文件包来实现跨平台的数据迁移，主要包含 Perl script xttdriver 和 xttdriver Perl 脚本。Perl script xttdriver.pl 是备份、转换、应用的执行脚本，xtt.properties 是属性文件，其中包含 XTTS 配置的路径、参数。 rman-xttconvert_2.0 包参数说明如下表： 6XTTS 迁移步骤（使用 RMAN 备份方法） 主要有以下步骤： 1）初始化参数设置； 2）将源端数据文件传输到目标系统； 3）转换数据文件为目标系统的字节序； 4）在源端创建增量备份，并传输到目标端； 5）在目标端恢复增量备份； 6）重复多次操作4和5步骤； 7）将源端数据库表空间设置为 READ ONLY 模式； 8）最后一次执行4和5步骤； 9）在源端导出元数据，并在目标端导入； 10）将目标端的数据库表空间设置为 READ WRITE； 11）数据验证。 6.1 XTTS 迁移准备阶段 6.1.1 生产库打开块跟踪特性 首先在生产库上打开块跟踪功能。 如果源库是 11g，延时段特性需要先禁用 alter system set deferred_segment_creation=false sid='*' scope=spfile; 不然 xtts 不会将空表导入目标库。 alter database enable block change tracking using file '/home/oracle/xtts/block_change_tracking.log'; 6.1.2 传输表空间前自包含检查  首先对表空间做自包含检查，检查出 Index 存在自包含问题，需要重建或者最后创建： SQL> execute dbms_tts.transport_set_check(‘DATATBS ’,true); PL/SQL procedure successfully completed. SQL> select * from transport_set_violations; XXXX 创建在 USERS 表空间，需要提前迁移至 DATATBS 表空间。 Drop index XXXX; CREATE INDEX XXXX ON "LUOKLE"."BI_LUOKLEINSTRUCTION" ("SENDTIME", "STATUS", "RECLUOKLE", "CREATORORGID", "CREATETIME") TABLESPACE DATATBS parallel 8; Alter index XXXX noparallel; 由于 XTTS 最后导入元数据时候不支持临时表，所以需要提前查出系统临时表信息。 select dbms_metadata.get_ddl('TABLE',TABLE_NAME,owner) from dba_tables where TEMPORARY='Y' and owner=XXX; 需要手工创建的临时表有X个，以下脚本导入元数据之后手工执行。 CREATE GLOBAL TEMPORARY TABLE XXX ( "_ID" NUMBER, "STATUS" CHAR(1) ) ON COMMIT PRESERVE ROWS ; 在表空间传输的中，要求表空间集为自包含的，自包含表示用于传输的内部表空间集没有引用指向外部表空间集。自包含分为两种：一般自包含表空间集和完全（严格）自包含表空间集。 常见的以下情况是违反自包含原则的： 索引在内部表空间集，而表在外部表空间集（相反地，如果表在内部表空间集，而索引在外部表空间集，则不违反自包含原则）；分区表一部分区在内部表空间集，一部分在外部表空间集（对于分区表，要么全部包含在内部表空间集中，要么全不包含）；如果在传输表空间时同时传输约束，则对于引用完整性约束，约束指向的表在外部表空间集，则违反自包含约束；如果不传输约束，则与约束指向无关；表在内部表空间集，而 lob 列在外部表空间集，则违反自包含约束。通常可以通过系统包 DBMS_TTS 来检查表空间是否自包含，验证可以以两种方式执行：非严格方式和严格方式。 以下是一个简单的验证过程，假定在 eygle 表空间存在一个表 eygle，其上存在索引存储在 USERS 表空间： SQL> create table eygle as select rownum id ,username from dba_users; SQL> create index ind_id on eygle(id) tablespace users; 以SYS用户执行非严格自包含检查（full_check=false）： 执行严格自包含检查（full_check=true）： 反过来对于 USERS 表空间来说，非严格检查也是无法通过的： 但是可以对多个表空间同时传输，则一些自包含问题就可以得到解决： 6.1.3 目标端创建数据库并修改部分参数 在目标环境需要提前安装好 GI 和 Oracle 软件，并创建监听、拷贝生产环境的 TNS 和新数据库，并修改部分数据库参数： create directory xtts_dir as 'home/oracle/xtts/'; grant read,write on directory xtts3 to public; 调整以下参数： alter system set "_optimizer_adaptive_cursor_sharing"=false sid='*' scope=spfile; alter system set "_optimizer_extended_cursor_sharing"=none sid='*' scope=spfile; alter system set "_optimizer_extended_cursor_sharing_rel"=none sid='*' scope=spfile; alter system set "_optimizer_use_feedback"=false sid ='*' scope=spfile; alter system set deferred_segment_creation=false sid='*' scope=spfile; alter system set event='28401 trace name context forever,level 1' sid='*' scope=spfile; alter system set resource_limit=true sid='*' scope=spfile; alter system set resource_manager_plan='force:' sid='*' scope=spfile; alter system set "_undo_autotune"=false sid='*' scope=spfile; alter system set "_optimizer_null_aware_antijoin"=false sid ='*' scope=spfile; alter system set "_px_use_large_pool"=true sid ='*' scope=spfile; alter system set audit_trail=none sid ='*' scope=spfile; alter system set "_partition_large_extents"=false sid='*' scope=spfile; alter system set "_index_partition_large_extents"= false sid='*' scope=spfile; alter system set "_use_adaptive_log_file_sync"=false sid ='*' scope=spfile; alter system set disk_asynch_io=true sid ='*' scope=spfile; alter system set db_files=2000 scope=spfile; alter profile "DEFAULT" limit PASSWORD_GRACE_TIME UNLIMITED; alter profile "DEFAULT" limit PASSWORD_LIFE_TIME UNLIMITED; alter profile "DEFAULT" limit PASSWORD_LOCK_TIME UNLIMITED; alter profile "DEFAULT" limit FAILED_LOGIN_ATTEMPTS UNLIMITED; exec dbms_scheduler.disable( 'ORACLE_OCM.MGMT_CONFIG_JOB' ); exec dbms_scheduler.disable( 'ORACLE_OCM.MGMT_STATS_CONFIG_JOB' ); BEGIN DBMS_AUTO_TASK_ADMIN.DISABLE( client_name => 'auto space advisor', operation => NULL, window_name => NULL); END; / BEGIN DBMS_AUTO_TASK_ADMIN.DISABLE( client_name => 'sql tuning advisor', operation => NULL, window_name => NULL); END; / 6.1.4 源端保留用户信息和权限 源端保留用户信息和权限： spool create_user_LUOKLE.sql select 'create user '||username||' identified by values '||''''||password||''''||';' from dba_users where default_tablespace in('TEST'); spool off 角色权限的语句： spool grant_role_priv_LUOKLE.sql select 'grant '||GRANTED_ROLE||' to '||grantee||';' from dba_role_privs where grantee in(select username from dba_users where default_tablespace in('TEST')); spool off sys 权限的赋权语句： spool grant_sys_priv_LUOKLE.sql select 'grant '||privilege||' to '||grantee||';' from dba_sys_privs where grantee in(select username from dba_users where default_tablespace in('TEST')); spool off 对表空间的配额权限语句： spool unlimited_tablespace_LUOKLE.sql select 'alter user '||username||' quota unlimited on DATATBS ||';' from dba_users where default_tablespace in('TEST'); spool off 附：若后期存在用户与其他非本用户的对象权限问题，如 Schema A 对 Schema B 上表的访问和操作等权限，可以使用以下语句在源库检索出权限，并在目标端数据库进行赋权即可： set line 200 set pages 0 spool grant_tab_priv.sql select 'grant ' || privilege || ' on ' || owner || '.' || table_name || ' to ' || grantee || ';' from dba_tab_privs where owner in (select username from dba_users where default_tablespace in('TEST')) or grantee in (select username from dba_users where default_tablespace in('TEST'')) and privilege in('SELECT','DELETE','UPDATE','INSERT') and grantable='NO' union select 'grant ' || privilege || ' on ' || owner || '.' || table_name || ' to ' || grantee || ' with grant option;' from dba_tab_privs where owner in (select username from dba_users where default_tablespace in('TEST')) or grantee in (select username from dba_users where default_tablespace in('TEST')) and privilege in('SELECT','DELETE','UPDATE','INSERT') and grantable='YES'; spool off 6.2 XTTS 迁移初始化阶段 6.2.1 源端更改配置文件 xtt.properties 更改以下参数： tablespaces=TEST,TEST_INDEX platformid=13 dfcopydir=/home/oracle/xtts/bak backupformat=/home/oracle/xtts/bakincr stageondest=/home/oracle/xtts/bak storageondest=+DATA/oracle11gasm/datafile backupondest=+DATA/oracle11gasm/datafile asm_home=/u01/app/grid/product/11.2.0/grid asm_sid=+ASM parallel=2 rollparallel=2 getfileparallel=2 更改配置之后，将整个 rman-xttconvert 目录传输至目标端。 6.2.2 源端进行迁移初始化 在源端进行初始化，即 backup as copy 的形式备份数据文件到 /aix_xtts/bak 下。 more full_backup.sh export TMPDIR=/aix_xtts perl xttdriver.pl -p 执行脚本进行全备： nohup sh ./full_back.sh >full_back.log & 初始化之后产生 xttplan.txt rmanconvert.cmd； xttplan.txt 记录了当前 SCN，也就是下次需要增量的开始 SCN； rmanconvert.cmd 记录了文件转换的名字。 [oracle@oracle11gasm xtts]$ cat rmanconvert.cmd host 'echo ts::TEST'; convert from platform 'Linux x86 64-bit' datafile '/home/oracle/xtts/bak/TEST_5.tf' format '+DATA/oracle11gasm/datafile/%N_%f.xtf' parallelism 2; host 'echo ts::TEST_INDEX'; convert from platform 'Linux x86 64-bit' datafile '/home/oracle/xtts/bak/TEST_INDEX_6.tf' format '+DATA/oracle11gasm/datafile/%N_%f.xtf' parallelism 2; 6.2.3 转换初始化文件至 ASM 中 由于使用了 NFS 不需要再次传输 /aix_xtts/bak，修改 xtt.properties 文件： 修改备库 xtt.properties 文件： 增加： asm_home=/oracle/app/grid/11.2.0.4 asm_sid=+ASM 该步骤中，我们需要在 Linux 目标端主机上完成，进行全库的数据文件转换，通过脚本直接将数据文件转换到 ASM DISKGROUP 中。 注意：该转换步骤中，我们只需要转换我们需要传输的业务表空间即可,也就是 DATATBS 。 如下是全库的转换脚本： more convert.sh export XTTDEBUG=1 export TMPDIR=/aix_xtts perl xttdriver.pl -c 执行脚本进行转换： nohup sh ./convert.sh >convert.log & 并且在目标的 storageondest 目录下会生成经转换后的数据文件拷贝。 日志如下： -------------------------------------------------------------------- Parsing properties -------------------------------------------------------------------- -------------------------------------------------------------------- Done parsing properties -------------------------------------------------------------------- -------------------------------------------------------------------- Checking properties -------------------------------------------------------------------- -------------------------------------------------------------------- Done checking properties -------------------------------------------------------------------- -------------------------------------------------------------------- Performing convert -------------------------------------------------------------------- -------------------------------------------------------------------- Converted datafiles listed in: /xtts/xttnewdatafiles.txt 转换成功之后会生成 xttnewdatafiles.txt，该文件为数据文件在 ASM MAP 关系表，即 file_id 和数据文件名对应表，增量恢复需要。 如果没有产生需要手工创建，命令格式如下： [oracle@oracle11gasm xtts]$ cat xttnewdatafiles.txt ::TEST 5,+DATA/oracle11gasm/datafile/test_5.xtf ::TEST_INDEX 6,+DATA/oracle11gasm/datafile/test_index_6.xtf 6.3 XTTS 迁移增量备份恢复 6.3.1 生产库进行第一次增量备份 由于生产库每天的归档极大，因此需要进行多次增量备份，并将增量备份传输到目标端 Linux 的新环境，并应用增量备份，其中初始化产生的 xttplan.txt 文件记录了增量 SCN 起始位置，这里我们只需要对需要传输的表空间进行增量备份即可： more do_incr.sh export TMPDIR=/aix_xtts perl xttdriver.pl –i 执行脚本进行增量备份： nohup sh ./do_incr.sh >do_incr_1.log & backup incremental from scn 13827379581 第一次增量备份开始的 SCN，由 -p 初始化产生； 增量8天的数据时间花费100分钟，产生增量文件40G。 [root@ecmsdb01plk xtts]# cat xttplan.txt.new --增量备份生成新的 xttplan.txt.new 文件 DATATBS ::::14000344337 --下一次增量备份开始的 SCN [oracle@oracle11g bakincr]$ pwd /home/oracle/xtts/bakincr [oracle@oracle11g bakincr]$ ls -lrt -rw-r----- 1 oracle oinstall 49152 Apr 1 08:00 0gsv7s0v_1_1 -rw-r----- 1 oracle oinstall 49152 Apr 1 08:00 0hsv7s10_1_1 第一次增量备份之后产生的2个配置文件为 tsbkupmap.txt 和 incrbackups.txt，这两个为增量与数据文件对应关系配置，在做增量恢复时候需要用到。 [oracle@oracle11gasm xtts]$ cat tsbkupmap.txt TEST_INDEX::6:::1=0hsv7s10_1_1 TEST::5:::1=0gsv7s0v_1_1 [oracle@oracle11gasm xtts]$ cat incrbackups.txt /home/oracle/xtts/bakincr/0hsv7s10_1_1 /home/oracle/xtts/bakincr/0gsv7s0v_1_1 通过 FTP 传输增量文件至目标 LINUX 环境。 ftp> put a0rj69fq_1_1 200 PORT command successful. 150 Opening data connection for a0rj69fq_1_1. 226 Transfer complete. 23119626240 bytes sent in 1395 seconds (1.618e+04 Kbytes/s) local: a0rj69fq_1_1 remote: a0rj69fq_1_1 ftp> ftp> ftp>put 9vrj66jc_1_1 200 PORT command successful. 150 Opening data connection for 9vrj66jc_1_1. 226 Transfer complete. 22823591936 bytes sent in 1381 seconds (1.614e+04 Kbytes/s) local: 9vrj66jc_1_1 remote: 9vrj66jc_1_1 两个窗口并行传输，花费时间25分钟，由于第一次增量数据较大整体消耗2个小时。 6.3.2 目标端进行第一次增量恢复 增量恢复前需要检查 xttnewdatafiles.txt（数据文件在 ASM 中 MAP 关系表）、tsbkupmap.txt 和 incrbackups.txt（增量与数据文件对应关系配置）、xttplan.txt（下次需要增量的开始 SCN）这些配置文件是否存在，如不存在会出现报错。 将增量备份集放置 /home/oracle/xtts/bak下，做增量恢复 more restore_incr.sh export TMPDIR=/home/oracle/xtts perl xttdriver.pl -r 执行脚本进行增量恢复： nohup sh ./restore_incr.sh >restore_incr.log & 第一次增量转换加恢复40G数据耗时30分钟。 如果在-r应用报 ORA-19638 错误，则需要把 xttplan.txt 使用前一次或前二次的。（因为多次的-i和-s会对 xttplan.txt 进行修改） 6.3.3 生成下次增量所需 SCN 配置文件 $ perl xttdriver.pl -s -------------------------------------------------------------------- Parsing properties -------------------------------------------------------------------- -------------------------------------------------------------------- Done parsing properties -------------------------------------------------------------------- -------------------------------------------------------------------- Checking properties -------------------------------------------------------------------- -------------------------------------------------------------------- Done checking properties -------------------------------------------------------------------- Prepare newscn for Tablespaces: 'DATATBS ' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: ''[oracle@ecmsdb01plk scripts_linux]$ perl xttdriver.pl -r -d Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' Prepare newscn for Tablespaces: '' New /oraexport/xtts/xttplan.txt with FROM SCN's generated [root@ecmsdb01plk xtts]# cat xttplan.txt DATATBS ::::14000344337 生产环境执行如上命令，产生最新 xttplan.txt 文件，下次增量备份开始 SCN 为 14000344337。 6.3.4 生产库进行第二次增量备份 生产环境进行第二次增量备份，此次增量备份一天数据： more do_incr.sh export TMPDIR=/home/oracle/xtts perl xttdriver.pl –i 执行脚本进行增量备份： nohup sh ./do_incr.sh >do_incr_1.log & backup incremental from scn 14000344337 第二次增量备份开始的 SCN。 第二次增量备份一天数据耗时5分钟。产生文件12G，通过 FTP 并行传输花费10分钟,总体二次增量备份一天数据耗时20分钟。 6.3.5 目标端进行第二次增量恢复 xttplan.txt 使用前一次的。 二次增量恢复一天数据，耗时15分钟： 6.4 XTTS 正式迁移 切割准备工作示意图 6.4.1 停止业务 业务部门停止应用程序。数据库检查当前会话，需要杀掉已经存在的会话。 set lines 132 pages 1111 trim on trims on spo machine_before_upgrade.txt select inst_id, machine, count(*) from gv$session where username!='SYS' group by inst_id, machine; spo off Kill 掉任然连接到数据库的会话： SELECT 'kill -9 '||SPID FROM V$PROCESS WHERE ADDR IN (SELECT PADDR FROM V$SESSION WHERE USERNAME != 'SYS'); 或 select 'alter system kill session '''||sid||','||serial#||''' immediate;' from v$session where USERNAME != 'SYS'; 6.4.2 生成最后一次增量备份 SCN 配置文件 $ perl xttdriver.pl -s 使用 xttdriver.pl –s生成最后一个 SCN 增量配置文件(即最后一次增量备份开始的SCN)，也可以手工修改 xttplan.txt。 6.4.3 生产库将表空间设置为只读 将业务表空间设置为只读模式，并开始最后一次的增量备份。 6.4.4 最后一次增量备份 sqlplus / as sysdba alter tablespace DATAtBS read only; 在源端中间环境进行最后一次增量备份： more do_incr.sh export TMPDIR=/home/oracle/xtts perl xttdriver.pl –i 执行脚本进行备份： nohup sh ./do_incr.sh >do_incr_1.log & 按照之前每天增量备份加传输大概耗时30分钟，在增量备份同时可以进行元数据的导出。 6.4.5 导出元数据（XTTS 元数据以及其他对象元数据） 在这个步骤中，我们可以并行同时导出 XTTS 的元数据以及其他的元数据，例如数据库存储过程，函数。触发器等等。 导出传输表空间元数据命令如下： create or replace directory xtts3 as '/oraexport/xtts/ ' exp \'/ as sysdba \' transport_tablespace=y tablespaces='DATATBS ' file=/oraexport/xtts/exp_DATATBS_xtts.dmp log=/oraexport/xtts/exp_DATATBS_xtts.log STATISTICS=none parallel=8 expdp \'/ as sysdba\' dumpfile=tts.dmp directory=xtts_dir logfile=expdp_xtts.log transport_tablespaces=TEST,TEST_INDEX exclude=STATISTICS; 导出元数据耗时2分钟。 导出其他对象数据如下： expdp \'/ as sysdba\' directory=xtts_dir dumpfile=expdp_LUOKLE_meta.dmp logfile=expdp_LUOKLE_meta.log CONTENT=metadata_only SCHEMAS=LUOKLE parallel=2; 导出其他数据耗时15分钟。 导出完成之后，将 dmp 文件传输到 Linux。 6.4.6 最后一次应用增量备份 将备份集放置 /oradata2 下，做增量恢复： more restore_incr.sh export TMPDIR=/home/oracle/xtts perl xttdriver.pl -r -d 执行脚本进行增量恢复： nohup sh ./restore_incr.sh >restore_incr.log & 根据之前增量恢复一天数据大概耗时15分钟。 6.4.7 导入 XTTS 元数据 通过如下命令将 xtts 表空间元数据导入到目标新库中： create or replace directory xtts_dir as '/home/oracle/xtts/'; impdp \'/ as sysdba\' dumpfile=expdp_tts.dmp directory=xtts_dir transport_tablespace=y datafiles='+DATA/ORACLE11GASM/DATAFILE/test_5.xtf,+DATA/ORACLE11GASM/DATAFILE/test_index_6.xtf'; 根据之前测试结果导入时间为10分钟左右。 6.4.8 目标端新库将表空间设置为读写模式 将业务表空间设置为可读写模式： sqlplus / as sysdba alter tablespace DATATBS read write; 6.4.9 目标端新库导入其他对象元数据 impdp \'/ as sysdba\' dumpfile=expdp_LUOKLE_meta.dmp directory=xtts_dir STATISTICS 如果不使用之前统计信息可用排除，最后收集。 原文发布时间为：2018-04-22 本文作者：罗贵林 本文来自云栖社区合作伙伴“数据和云”，了解相关信息可以关注“数据和云”。

【引言】本文档建立在针对HP EVA的大量测试性研究基础上，所有的细节几乎均为对EVA的破译型研究，目前全球范围内尚未发现类似资料，故可能表述方式和结论并不精确，仅为参考之用。我们公司为研究HP EVA系列算法，花费了大量的人力物力，目前应为全国唯一的研究此项技术的公司，转载请注明来源。 【前因】HP EVA4400/6400/8400因接近退役，已进入高故障区间，用户往往会认为花费几十万甚至上百万购买的eva系列应该是非常稳定的，但实际上无论多么昂贵的存储设备，使用的磁盘是相同或相似的。正如eva上销量极大的部件号为454414-001的1T FATA磁盘，其实就是臭名昭彰的希捷7200.11 系列的FC版，虽然前者正品售价仍高达近4K，后者却不足400，但两者的性能和稳定性表现几乎是相同的。这些1T FATA磁盘在经历2-3年的运行后，总会出现大批量的损坏，而且往往一旦损坏，几乎很难修复。一个我遇到的最夸张的案例，108块1T FATA的EVA6400，在半年内先后损坏50多块，这是让人惊讶的，实则也是正常的(缘于希捷这款产品的设计缺陷)。即便是使用15000rpm或10000rpm的FC磁盘，其实盘体也等同于希捷、日立等厂商的SAS磁盘(目前的EVA系列磁盘已经全部基于SAS了，即使是FC，也是通过转换电路实现SAS到FC的转换，如671148-001)。EVA是虚拟化的存储设备，平时数据会不断的迁移，加上应用通常较为繁重，所以磁盘的负载相对是较重的，也是很容易出现故障的。EVA是依靠大量磁盘的冗余空间，以及故障后rss冗余磁盘动态迁移来实现整个存储的数据保护，但随着越来越多的磁盘掉线，这种保护会接近临界，直至崩溃。通过eva command view下的 fieldservice执行强制激活命令，一则会导致cache dirty、数据块结构不一致导致数据出现损坏。二则修复只能建立在绕开坏道区域的基础上，如果坏道无法绕开，也是徒劳。另有一些情况：主机无法与扩展柜相连导致数据丢失，误删除vdisk等，也需要有切实的解决方案。HP P6000系列控制器与EVA系列内部算法完全相同，不再单独提及。【eva系列存储结构原理概述】 EVA系列存储是一款以虚拟化存储为实现目的的HP中高端存储设备，内部的结构组成完全不同于普通的基于简单RAID的存储，EVA内部称之为VRAID。包括一些资深的HP工程师，对EVA的理解其实是有误区的(也可能是HP官方的宏观描述)EVA会对每个物理磁盘(简称为PV)进行签名(写在每个磁盘的0扇区)，签名后即分配进不同的DISK GROUP。在disk group中，类似于aix 的卷管理，或HP LVM的卷管理一样，每个PV会按一定大小划分为若干存储单元(按AIX的说法，暂且称为PP吧)，PP的大小为2的整数次幂，且应该在2-16M之间。每个PV中有有限数量的PP，这些PP合起来形成整个DISK GROUP的可用空间。所有的PV按5-15组成若干组RSS(HP的官方资料中讲最小的RSS磁盘数量是6，最大应不到15，但对底层的分析得知，存在5和15个PV的RSS情况)，每个RSS就是一个所谓常规RAID的冗余组，但这个冗余组不等同于常规RAID，与常规RAID相似的是，常规RAID是以磁盘为单位的RAID算法，而RSS是基于PP的RAID算法。为提高性能，HP EVA会有倾向地轮流分配不同的RSS组，但这些RSS之间的数据存储是基于JBOD的(HP官方和很多资料上称是RAID0，或许是宏观的概念)，每个RSS组成的stripe 的成员其实是不同PV中不同位置的PP。无论RSS中成员数量有多少个，对于VRAID5，一个stripe中的PV数总是5个。对于VRAID6，一个stripe中的PV数总是6个。例如，对于VRAID5，EVA会尽可能在N个磁盘中做C(N,5)的组合情况，以期实现IO 负载均衡。当一个RSS中某个PV离线，控制器会从同一个RSS组中其他磁盘(同一条带中已存在的PV之外)中寻找可用的PP，在逻辑上实现每个stripe的rebuild，从而保证整个存储的安全性。当一个RSS中损坏的磁盘数量足够少时(少于等于6个)，这个RSS的安全性就非常低了，这时候，EVA会合并此RSS到另一个RSS中，这样可用的冗余空间就是共享的了，空间就可以从另一个较安全的RSS中迁移过来。为了保证有足够的空间提供冗余保护，在创建disk group时，EVA会提供一个Protection Level的保护级别，single表示用2个磁盘的空间做冗余 ，double表示用4个磁盘的空间做冗余。但这个冗余不同于hotspare，这个冗余空间仅会预留到每个PV的尾部，一则，多个磁盘，IO会更均匀，更快；二则，尾部的空间通常是质量较差的空间。 【EVA系列常见故障】1、RSS中多个磁盘掉线，超过冗余保护级别。2、加入新磁盘，进行数据迁移时，新磁盘存在物理故障(此时无法回退，也无法前进)。3、VDISK 删除或EVA initialize。4、突发性主机与存储无法连接。无法discover到存储。 【数据恢复解决原理】eva系列最核心的结构部分来自于所有vdisk的运算pp表，这个pp map表会因为磁盘的不断迁移而迁移。所有的故障均可基于此map进行恢复。当pp map不存在时，根据不同的条带之间的冗余关系，可有优化算法对所有PP进行条带性集合，从而形成若干组正确的条带数据，再基于文件系统结构、数据结构等特征，重组若干条带。 【数据恢复解决过程】1、原始磁盘镜像，将EVA主机一端的连线拔出，直接连入主机hba卡上，就可以认到所有物理硬盘，之后通过专业手段(Linux下的dd，windows下的winhex等)进行磁盘镜像。因eva主机与扩展柜之间多是铜线连接，故而，可能需要在扩展柜上增加光纤收发模块，再通过光链路接入fc hba卡上。当然，也可以把所有硬盘拆下来后，放入其他光纤通道柜中进行镜像。使用EVA扩展柜进行镜像的连接图如下： 2、通过frombyte recovery for hp eva程序进行vdisk重组，直接写入成镜像文件或目标物理磁盘。3、按常规方式解释镜像文件或目标磁盘，迁移镜像或导出内部文件。

【引言】 本文档建立在针对HP EVA的大量测试性研究基础上，所有的细节几乎均为对EVA的破译型研究，目前全球范围内尚未发现类似资料，故可能表述方式和结论并不精确，仅为参考之用。 北亚数据恢复中心(www.datahf.net)为研究HP EVA系列算法，花费了大量的人力物力，目前应为全国唯一的研究此项技术的公司，转载请注明来源。 【前因】 HP EVA4400/6400/8400因接近退役，已进入高故障区间，用户往往会认为花费几十万甚至上百万购买的eva系列应该是非常稳定的，但实际上无论多么昂贵的存储设备，使用的磁盘是相同或相似的。正如eva上销量极大的部件号为454414-001的1T FATA磁盘，其实就是臭名昭彰的希捷7200.11 系列的FC版，虽然前者正品售价仍高达近4K，后者却不足400，但两者的性能和稳定性表现几乎是相同的。这些1T FATA磁盘在经历2-3年的运行后，总会出现大批量的损坏，而且往往一旦损坏，几乎很难修复。一个我遇到的最夸张的案例，108块1T FATA的EVA6400，在半年内先后损坏50多块，这是让人惊讶的，实则也是正常的(缘于希捷这款产品的设计缺陷)。 即便是使用15000rpm或10000rpm的FC磁盘，其实盘体也等同于希捷、日立等厂商的SAS磁盘(目前的EVA系列磁盘已经全部基于SAS了，即使是FC，也是通过转换电路实现SAS到FC的转换，如671148-001)。EVA是虚拟化的存储设备，平时数据会不断的迁移，加上应用通常较为繁重，所以磁盘的负载相对是较重的，也是很容易出现故障的。EVA是依靠大量磁盘的冗余空间，以及故障后rss冗余磁盘动态迁移来实现整个存储的数据保护，但随着越来越多的磁盘掉线，这种保护会接近临界，直至崩溃。 通过eva command view下的 fieldservice执行强制激活命令，一则会导致cache dirty、数据块结构不一致导致数据出现损坏。二则修复只能建立在绕开坏道区域的基础上，如果坏道无法绕开，也是徒劳。 另有一些情况：主机无法与扩展柜相连导致数据丢失，误删除vdisk等，也需要有切实的解决方案。 HP P6000系列控制器与EVA系列内部算法完全相同，不再单独提及。 【eva系列存储结构原理概述】 EVA系列存储是一款以虚拟化存储为实现目的的HP中高端存储设备，内部的结构组成完全不同于普通的基于简单RAID的存储，EVA内部称之为VRAID。包括一些资深的HP工程师，对EVA的理解其实是有误区的(也可能是HP官方的宏观描述) EVA会对每个物理磁盘(简称为PV)进行签名(写在每个磁盘的0扇区)，签名后即分配进不同的DISK GROUP。在disk group中，类似于aix 的卷管理，或HP LVM的卷管理一样，每个PV会按一定大小划分为若干存储单元(按AIX的说法，暂且称为PP吧)，PP的大小为2的整数次幂，且应该在2-16M之间。 每个PV中有有限数量的PP，这些PP合起来形成整个DISK GROUP的可用空间。所有的PV按5-15组成若干组RSS(HP的官方资料中讲最小的RSS磁盘数量是6，最大应不到15，但对底层的分析得知，存在5和15个PV的RSS情况)，每个RSS就是一个所谓常规RAID的冗余组，但这个冗余组不等同于常规RAID，与常规RAID相似的是，常规RAID是以磁盘为单位的RAID算法，而RSS是基于PP的RAID算法。 为提高性能，HP EVA会有倾向地轮流分配不同的RSS组，但这些RSS之间的数据存储是基于JBOD的(HP官方和很多资料上称是RAID0，或许是宏观的概念)，每个RSS组成的stripe 的成员其实是不同PV中不同位置的PP。 无论RSS中成员数量有多少个，对于VRAID5，一个stripe中的PV数总是5个。对于VRAID6，一个stripe中的PV数总是6个。例如，对于VRAID5，EVA会尽可能在N个磁盘中做C(N,5)的组合情况，以期实现IO 负载均衡。 当一个RSS中某个PV离线，控制器会从同一个RSS组中其他磁盘(同一条带中已存在的PV之外)中寻找可用的PP，在逻辑上实现每个stripe的rebuild，从而保证整个存储的安全性。 当一个RSS中损坏的磁盘数量足够少时(少于等于6个)，这个RSS的安全性就非常低了，这时候，EVA会合并此RSS到另一个RSS中，这样可用的冗余空间就是共享的了，空间就可以从另一个较安全的RSS中迁移过来。 为了保证有足够的空间提供冗余保护，在创建disk group时，EVA会提供一个Protection Level的保护级别，single表示用2个磁盘的空间做冗余 ，double表示用4个磁盘的空间做冗余。但这个冗余不同于hotspare，这个冗余空间仅会预留到每个PV的尾部，一则，多个磁盘，IO会更均匀，更快；二则，尾部的空间通常是质量较差的空间。 【EVA系列常见故障】 1、RSS中多个磁盘掉线，超过冗余保护级别。 2、加入新磁盘，进行数据迁移时，新磁盘存在物理故障(此时无法回退，也无法前进)。 3、VDISK 删除或EVA initialize。 4、突发性主机与存储无法连接。无法discover到存储。 【数据恢复解决原理】 eva系列最核心的结构部分来自于所有vdisk的运算pp表，这个pp map表会因为磁盘的不断迁移而迁移。所有的故障均可基于此map进行恢复。 当pp map不存在时，根据不同的条带之间的冗余关系，可有优化算法对所有PP进行条带性集合，从而形成若干组正确的条带数据，再基于文件系统结构、数据结构等特征，重组若干条带。 【数据恢复解决过程】 1、原始磁盘镜像，将EVA主机一端的连线拔出，直接连入主机hba卡上，就可以认到所有物理硬盘，之后通过专业手段(Linux下的dd，windows下的winhex等)进行磁盘镜像。因eva主机与扩展柜之间多是铜线连接，故而，可能需要在扩展柜上增加光纤收发模块，再通过光链路接入fc hba卡上。当然，也可以把所有硬盘拆下来后，放入其他光纤通道柜中进行镜像。镜像方案见http://zhangyu.blog.51cto.com/197148/138974 使用EVA扩展柜进行镜像的连接图如下： 2、通过北亚frombyte recovery for hp eva程序进行vdisk重组，直接写入成镜像文件或目标物理磁盘。 3、按常规方式解释镜像文件或目标磁盘，迁移镜像或导出内部文件。 本文转自 张宇 51CTO博客，原文链接：http://blog.51cto.com/zhangyu/1328635，如需转载请自行联系原作者

【引言】 本文档建立在针对HP EVA的大量测试性研究基础上，所有的细节几乎均为对EVA的破译型研究，目前全球范围内尚未发现类似资料，故可能表述方式和结论并不精确，仅为参考之用。 北亚数据恢复中心(www.datahf.net)为研究HP EVA系列算法，花费了大量的人力物力，目前应为全国唯一的研究此项技术的公司，转载请注明来源。 【前因】 HP EVA4400/6400/8400因接近退役，已进入高故障区间，用户往往会认为花费几十万甚至上百万购买的eva系列应该是非常稳定的，但实际上无论多么昂贵的存储设备，使用的磁盘是相同或相似的。正如eva上销量极大的部件号为454414-001的1T FATA磁盘，其实就是臭名昭彰的希捷7200.11 系列的FC版，虽然前者正品售价仍高达近4K，后者却不足400，但两者的性能和稳定性表现几乎是相同的。这些1T FATA磁盘在经历2-3年的运行后，总会出现大批量的损坏，而且往往一旦损坏，几乎很难修复。一个我遇到的最夸张的案例，108块1T FATA的EVA6400，在半年内先后损坏50多块，这是让人惊讶的，实则也是正常的(缘于希捷这款产品的设计缺陷)。 即便是使用15000rpm或10000rpm的FC磁盘，其实盘体也等同于希捷、日立等厂商的SAS磁盘(目前的EVA系列磁盘已经全部基于SAS了，即使是FC，也是通过转换电路实现SAS到FC的转换，如671148-001)。EVA是虚拟化的存储设备，平时数据会不断的迁移，加上应用通常较为繁重，所以磁盘的负载相对是较重的，也是很容易出现故障的。EVA是依靠大量磁盘的冗余空间，以及故障后rss冗余磁盘动态迁移来实现整个存储的数据保护，但随着越来越多的磁盘掉线，这种保护会接近临界，直至崩溃。 通过eva command view下的 fieldservice执行强制激活命令，一则会导致cache dirty、数据块结构不一致导致数据出现损坏。二则修复只能建立在绕开坏道区域的基础上，如果坏道无法绕开，也是徒劳。 另有一些情况：主机无法与扩展柜相连导致数据丢失，误删除vdisk等，也需要有切实的解决方案。 HP P6000系列控制器与EVA系列内部算法完全相同，不再单独提及。 【eva系列存储结构原理概述】 EVA系列存储是一款以虚拟化存储为实现目的的HP中高端存储设备，内部的结构组成完全不同于普通的基于简单RAID的存储，EVA内部称之为VRAID。包括一些资深的HP工程师，对EVA的理解其实是有误区的(也可能是HP官方的宏观描述) EVA会对每个物理磁盘(简称为PV)进行签名(写在每个磁盘的0扇区)，签名后即分配进不同的DISK GROUP。在disk group中，类似于aix 的卷管理，或HP LVM的卷管理一样，每个PV会按一定大小划分为若干存储单元(按AIX的说法，暂且称为PP吧)，PP的大小为2的整数次幂，且应该在2-16M之间。 每个PV中有有限数量的PP，这些PP合起来形成整个DISK GROUP的可用空间。所有的PV按5-15组成若干组RSS(HP的官方资料中讲最小的RSS磁盘数量是6，最大应不到15，但对底层的分析得知，存在5和15个PV的RSS情况)，每个RSS就是一个所谓常规RAID的冗余组，但这个冗余组不等同于常规RAID，与常规RAID相似的是，常规RAID是以磁盘为单位的RAID算法，而RSS是基于PP的RAID算法。 为提高性能，HP EVA会有倾向地轮流分配不同的RSS组，但这些RSS之间的数据存储是基于JBOD的(HP官方和很多资料上称是RAID0，或许是宏观的概念)，每个RSS组成的stripe 的成员其实是不同PV中不同位置的PP。 无论RSS中成员数量有多少个，对于VRAID5，一个stripe中的PV数总是5个。对于VRAID6，一个stripe中的PV数总是6个。例如，对于VRAID5，EVA会尽可能在N个磁盘中做C(N,5)的组合情况，以期实现IO 负载均衡。 当一个RSS中某个PV离线，控制器会从同一个RSS组中其他磁盘(同一条带中已存在的PV之外)中寻找可用的PP，在逻辑上实现每个stripe的rebuild，从而保证整个存储的安全性。 当一个RSS中损坏的磁盘数量足够少时(少于等于6个)，这个RSS的安全性就非常低了，这时候，EVA会合并此RSS到另一个RSS中，这样可用的冗余空间就是共享的了，空间就可以从另一个较安全的RSS中迁移过来。 为了保证有足够的空间提供冗余保护，在创建disk group时，EVA会提供一个Protection Level的保护级别，single表示用2个磁盘的空间做冗余 ，double表示用4个磁盘的空间做冗余。但这个冗余不同于hotspare，这个冗余空间仅会预留到每个PV的尾部，一则，多个磁盘，IO会更均匀，更快；二则，尾部的空间通常是质量较差的空间。 【EVA系列常见故障】 1、RSS中多个磁盘掉线，超过冗余保护级别。 2、加入新磁盘，进行数据迁移时，新磁盘存在物理故障(此时无法回退，也无法前进)。 3、VDISK 删除或EVA initialize。 4、突发性主机与存储无法连接。无法discover到存储。 【数据恢复解决原理】 eva系列最核心的结构部分来自于所有vdisk的运算pp表，这个pp map表会因为磁盘的不断迁移而迁移。所有的故障均可基于此map进行恢复。 当pp map不存在时，根据不同的条带之间的冗余关系，可有优化算法对所有PP进行条带性集合，从而形成若干组正确的条带数据，再基于文件系统结构、数据结构等特征，重组若干条带。 【数据恢复解决过程】 1、原始磁盘镜像，将EVA主机一端的连线拔出，直接连入主机hba卡上，就可以认到所有物理硬盘，之后通过专业手段(Linux下的dd，windows下的winhex等)进行磁盘镜像。因eva主机与扩展柜之间多是铜线连接，故而，可能需要在扩展柜上增加光纤收发模块，再通过光链路接入fc hba卡上。当然，也可以把所有硬盘拆下来后，放入其他光纤通道柜中进行镜像。镜像方案见http://zhangyu.blog.51cto.com/197148/138974 使用EVA扩展柜进行镜像的连接图如下： 2、通过北亚frombyte recovery for hp eva程序进行vdisk重组，直接写入成镜像文件或目标物理磁盘。 3、按常规方式解释镜像文件或目标磁盘，迁移镜像或导出内部文件。 本文转自 张宇 51CTO博客，原文链接：http://blog.51cto.com/zhangyu/1328635，如需转载请自行联系原作者