干我们这行的，谁没被数据库折磨过几个通宵呢？前两天我那个做财务系统的哥们儿，半夜三点给我打电话，声音带着哭腔——“库崩了，三月份的报表全没了，明天老板就要看数据。”我问他备份呢？他说平时都是点一下“导出”就完事了，结果这次导出来的文件打不开。这事儿让我想起自己刚入行时，被 PL/SQL 折腾得够呛，备份还原这活儿看着简单，里头的水可深着呢。今天就聊聊这个话题。
先说备份。很多人觉得备份就是点一下“导出”，然后找个文件夹存着就完事了，这想法太天真了。PL/SQL Developer 里那个“导出”功能，选项多到让人眼花——有 “Oracle Export” 和 “PL/SQL Developer” 两种模式，前者用的是 Oracle 原生的 exp 工具，后者是 PL/SQL Developer 自己的一套。我见过有人选了 PL/SQL Developer 模式，导出来的 .sql 文件能打开，但里头全是 INSERT 语句，一个表几百万条数据，文件会大到几十个 GB。等你需要还原时，光执行这些 INSERT 语句就要跑上几个小时。更坑的是，中途要是网络断了或者内存不够，前功尽弃。所以我的建议是，数据量超过 10 万条的表，老老实实用 “Oracle Export” 模式，生成 .dmp 文件，效率高得多。
再说备份策略。我见过最离谱的做法是有人每周五下班前导一次，然后回家睡大觉。结果周三下午库出问题了，数据只恢复到上周五的状态，中间三天的工作全白干了。备份频率得跟业务重要性挂钩。核心业务系统，一天至少一次全量备份，再加上每小时的增量备份。PL/SQL Developer 里有个 “Schedule” 功能可以设置定时任务，但说实话，我更喜欢用 Windows 的任务计划程序来调用 exp 命令，这样更稳定，不会因为 PL/SQL Developer 没打开就漏掉备份。另外，备份文件千万别只放在 C 盘，也别只放在服务器本地。我有个朋友就是吃了这个亏，服务器硬盘坏了，备份和源文件一起报销。异地备份、云存储，哪怕把一个副本放在移动硬盘里，也比只有一个副本强。
还原这块儿，坑更多。很多人以为还原就是双击备份文件，然后点“确定”，结果碰上一堆报错。最常见的是 “ORA-01691: unable to extend table”，意思是表空间不够了。这通常是因为还原时没注意源库和目标库的表空间大小是否匹配。我的做法是，先查一下源库的表空间配置，用 看每个表空间实际用了多少。然后在目标库里先创建足够的表空间，再把还原命令里的 和 参数配好，这样基本就不会出幺蛾子。还有一个容易忽略的点是字符集不一致。源库是 AL32UTF8，目标库是 ZHS16GBK，恢复出来的数据全是乱码。可以提前用 检查两边字符集，不一致的话，要么改目标库的设置，要么用转换工具。
PL/SQL Developer 的还原功能其实挺智能的，但得会用。比如 “Import Tables” 功能，选好 .dmp 文件后会弹出窗口，让你挑哪些表要还原，哪些不要。这个设计本是为了灵活，但很多人直接全选，结果把一些临时表、日志表也还原进去了，目标库里堆满冗余数据。我的习惯是，先用 “Export Viewer” 看一下备份文件里到底有哪些对象，然后在还原时只勾选核心业务表。还有 “Replace existing objects” 选项默认是勾上的，如果你只是想补全数据而不想覆盖已有结构，记得把它取消，否则可能把目标库里自己建的索引、触发器冲掉。
说到索引和触发器，这是很多人忽略的细节。用 PL/SQL 还原数据时，默认会把索引和约束也带过去，但有时候会出问题。比如源库里有个唯一索引，目标库里已经有重复数据，恢复时就会报错，整个过程卡住。解决办法是，在还原之前手动把目标库里对应的索引和约束删掉，等数据还原完再重新创建。虽然多了一步，但能省掉后面排错的功夫。触发器也是大麻烦。有些触发器是 “before insert” 类型的，往表里插数据时会自动执行，如果触发器里调用了别的表，而还原顺序不对，就会报 “ORA-04088: trigger execution failed”。建议在还原大表之前先把所有触发器禁用，用 ，等数据全部到位后再逐个启用。
还有一种情况是还原过程中网络断了。PL/SQL Developer 的还原是单线程的，一旦中断只能从头再来。我曾经还原一个 200 GB 的库，跑了快四个小时，结果网线被保洁阿姨踢掉了，真是崩溃。后来我改用 Oracle 自带的 impdp 工具，它支持并行处理，而且可以断点续传。虽然操作比 PL/SQL 复杂一点，需要在命令行敲参数，但稳定性好太多。具体做法是，先用 expdp 生成备份文件，再用 impdp 还原，加入 参数，速度能提升好几倍；如果中途断了，使用 和 等参数，能够继续执行，不会白忙活。
说点实在的。备份还原这事儿技术门槛不高，难的是养成习惯和应对突发状况。我见过有人把备份脚本写好了，却从未测试过还原流程，等真出事才发现导出文件是坏的。我的建议是，每个月至少做一次 “还原演练”，挑一个测试环境，把最近的备份文件还原进去，核对数据是否完整。这就像消防演习，平时多流汗，战时少流血。另外，PL/SQL Developer 有个 “Export User Objects” 功能，可以单独导出存储过程、函数等代码对象，别嫌麻烦，每次改完代码就顺手导一份，万一上线出问题，至少代码能回滚。数据库是你的饭碗，别等它碎了才想起珍惜。
