很多金蝶EAS或HR系统的后台 ORACLE 数据库都处于无备份且未打开归档的状态，由于一般企业对于EAS或HR系统的后台数据库没有专职的DBA维护，所以实际也不推荐真的开归档并基于归档做备份维护，因为这样做会多一点维护的工作量（如果你是大企业 那么理应打开归档并维护归档以满足自身的备份恢复要求，例如大企业要求数据能回溯到一个月前，那么有归档才是合适的。）
对于中小企业使用金蝶EAS或HR系统而言，视乎系统后台ORACLE数据库的大小和可容忍的数据丢失时间，可以自主选择逻辑备份周期。这里说的逻辑备份主要是指ORACLE自带的EXPDP 数据泵导出工具，一般来说目前的金蝶EAS/HR用户的后台ORACLE数据库都是大于版本9i的版本（例如10g和11g等），则都可以选择使用EXPDP，其好处是逻辑导出备份要比传统export/import工具的exp速度上要快很多，且其导出格式也比exp周全。
一般来说中小企业大多可以容忍一天到半天的数据丢失，这部分的数据丢失一般可以基于财务或人力部分的同事通过手工补录来弥补，则对于这种场景下可以规划每12小时或24小时做一次逻辑备份：注意逻辑备份的频率就决定了数据丢失的量，因为逻辑备份是就是一次对数据的全量备份，每一次逻辑备份都是对现有数据的全量备份；所以周一中午12点备份的数据，在周二上午12点备份前的周一下午6点发生了数据库损坏/毁灭等问题，则周一中午到下午6点间产生的数据将可能丢失。
对于逻辑备份而言，其实维护的命令很简单：
expdp DIRECTORY=(备份存放的目录，需要在ORACLE内以CREATE DIRECTORY创建) dumpfile=(备份的文件名，会放在DIRECTORY下) schemas=(EAS或HR所在的Schema) logfile=(日志的文件名，会放在DIRECTORY下） parallel=2
例如 备份的目录叫DMP，EAS或HR所在schema伟EAS1和SHR1 则
expdp DIRECTORY=DMP dumpfile=kingdee_20170315.dmp schemas=eas1,shr1 logfile=exp_20170315.log parallel=2
对于Windows可以使用计划任务，对于Unix/Linux可以使用crontab自动调度以上备份脚本；另脚本内一般要考虑删除多久之前的备份文件。
此外要考虑 逻辑备份一般都是备份在数据库所在服务器，若服务器出现主机故障则恢复将较为麻烦，因此一般会考虑则EXPDP逻辑备份后FTP或COPY到其他远程服务器的磁盘上，以便冗余备份。
例如在 Linux下 定期备份并传到到FTP服务器上：
#!/bin/sh ORACLE_HOME=/home/app/oracle/product/11.2.0/dbhome_1 export ORACLE_HOME export PATH=$ORACLE_HOME/bin:$PATH ORACLE_SID=orcl; export ORACLE_SID HOST='IP地址' USER='ftpuser' PASSWD='password' expdp eas/SHITANRUANJIAN DIRECTORY=backdir DUMPFILE=eas-$(date +%Y%m%d%H) VERSION=10.2 LOGFILE=easLOG-$(date +%Y%m%d%H).log zip -r /home/app/oracle/admin/orcl/dpdump/eas-$(date +%Y%m%d%H).zip /home/app/oracle/admin/orcl/dpdump/eas-$(date +%Y%m%d%H).dmp cat /home/app/oracle/admin/orcl/dpdump/easLOG-$(date +%Y%m%d%H).log | mutt -s "eas Backup" [email protected] cd /home/app/oracle/admin/orcl/dpdump ftp -n -v $HOST << EOT binary user $USER $PASSWD prompt put eas-$(date +%Y%m%d%H).zip bye EOT find /home/app/oracle/admin/orcl/dpdump -name "eas*" -mtime +10 -type f -exec rm {} ;
如上脚本首先备份EAS用户并FTP到备份服务器上，最后删除10天前的备份。
如上描述了对金蝶EAS的备份方案，之后谈一下恢复方案；使用EXPDP的备份方案后,若出现大规模的数据库问题 例如ORACLE数据库打不开或出现大量坏块或ORACLE
所在服务器出现故障无法启动。则可以在必要的可用服务器上安装与之前ORACLE版本一样的ORACLE数据库软件，之后使用DBCA工具创建新的数据库，最后
使用IMPDP工具将之前的备份导入数据库中。
导入命令也十分简单：
impdp DIRECTORY=(备份所存放的目录，需要在ORACLE内以CREATE DIRECTORY创建) dumpfile=(备份的文件名) logfile=(日志的文件名，会放在DIRECTORY下） parallel=2 full=y
其他的一些恢复场景下的恢复方案：
由于 EAS/HR 运行在 NOARCHIVELOG 模式下，针对不同的故障场景下可以采取以下恢复策略：
1. SPFILE 初始化参数文件物理损坏：
从 PFILE 中重新生成一个 SPFILE
CREATE SPFILE=’’ FROM PFILE=’’
或者从备份中恢复
RESTORE SPFILE TO PFILE=’’;
RESTORE SPFILE;
RESTORE SPFILE FROM AUTOBACKUP;
2. Control File 文件部分物理损坏：
关闭数据库，将其它完整的控制文件复制到已损坏的控制文件，重启数据库
3. Control File 文件全部物理损坏 在数据库关闭时或者出于 mounted 时，即数据库处于一致性状态时 control file 全部物 理损坏，则执行 create controlfile 命令重新创建控制文件，如果处于非一致性状态时 损坏，则通过最新的物理备份全库恢复，然后追加备份发生时到故障点之间的数据。
4. 非 CURRENT 在线日志文件物理损坏 执行 alter database clear logfile 语句重新创建该损坏的非 CURRENT 在线日志文件
5. CURRENT 在线日志文件物理损坏
SQL> startup mount
SQL> recover database until cancel; #(cancel immediately)
SQL> alter database open resetlogs;
6. SYSTEM,SYSAUX,UNDO 表空间物理文件物理损坏 ：
通过最新的逻辑备份全库恢复
7. TEMP 表空将物理文件物理损坏
执行＂alter database”重新创建 temp 物理文件
8. 用户数据表空间物理文件物理损坏
通过最新的逻辑备份全库恢复
9. 用户索引表空间物理文件物理损坏
重新创建用户索引表空间，然后 rebuilt 相应的索引
10. 物理快损坏
如果该损坏块为用户索引，则 rebuilt 相应的索引
如果该损坏块为用户表，则通过设置 event 将没有损坏的数据正常读出来（损坏块中的数据库会丢失）或者通过关键表的逻辑备份恢复
如果该损坏块为系统数据，通过最新的逻辑备份全库恢复
11. 用户表数据不正常更新(INSERT、UPDATE、DELETE)
可以通过关键表的逻辑备份恢复，或者相应的 flashback 技术恢复
12. 用户表不正常删除(drop)
可以通过关键表的逻辑备份恢复，或者 flashback drop 技术恢复
如果上述方案还不能搞定你的EAS/HR后台ORACLE数据库的问题那么也可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
Leave a Reply