简介这是一份面向Oracle数据库运维工程师与ETL开发人员的轻量级Shell数据卸载工具包解决日常批量导出结构化数据至文本文件的自动化需求。资源共4个文件含2个配置型txtSQL模板与输出文件名、1个核心shell脚本poolfile.sh及1个环境配置config文件总大小仅4KB结构精简、即配即用。已有868人学习下载说明其在中小规模数据导出场景中具备较强实用性。用户可快速完成Oracle数据卸载、GBK→UTF8编码转换、动态批次号生成、尾行自动追加记录数、FTP上传等全流程操作脚本内嵌大文件切割逻辑注释便于按需启用所有配置集中于/etl/sql/与/etl/shell/config路径环境适配清晰适合Shell基础扎实、需高效落地数据导出任务的中级DBA或数据工程师。1. 为什么一个“卸载数据模板”的 shell 脚本比写十个存储过程还让 DBA 睡不着觉你不是在删一张表也不是在清空一个 schema——你在 Oracle 数据库里执行一次可逆、可审计、可回滚、带依赖校验、跨环境一致的「数据模板卸载」。这个动作常出现在EBS/WIP 模块升级前清理测试工单、PAC 成本法切换时剥离旧成本模板、ERP 多租户环境迁移后回收客户专属配置。它不是DROP TABLE那么简单模板往往散落在WIP_DISCRETE_JOBS、BOM_STRUCTURES_B、CST_COST_ELEMENTS等十几张核心表里有外键级联、有触发器拦截、有物化视图依赖、还有DBMS_SCHEDULER任务在后台偷偷刷新。用 SQLPlus 手敲漏一条关联记录第二天生产工单就卡在「WIP 工单状态异常」用 PL/SQL 包封装部署时权限报错、版本不兼容、日志无痕出问题连哪一行没执行都查不到。而一个真正能落地的 shell 脚本必须同时扛住三件事连接层的 Oracle 客户端稳定性tnsnames.ora / sqlnet.ora 兼容性、SQL 执行层的事务原子性与错误捕获、操作系统层的文件锁与并发安全。这不是 shell 入门教程里的for i in *.log; do rm $i; done这是把 Linux 进程控制、Oracle 会话生命周期、SQLPlus 的 exit code 解析全拧在一起的黑匣子。本文只讲一件事怎么写出一个上线前被 DBA 和运维双签字放行的uninstall_template.sh——它不炫技但每次执行后你能指着日志说“删了 37 条主模板记录、级联清理 129 行子项、归档了 4.2MB 原始数据、所有触发器状态已验证、回滚点已标记”。2. 模板卸载的本质不是删数据而是执行一次受控的「反向部署」2.1 为什么不能直接用 SQL*Plus -S 执行 DELETE三个硬伤必须堵死很多工程师第一反应是写个.sql文件然后sqlplus -S /nolog EOF ...。这在开发环境跑得飞快一上生产就翻车。根本原因在于 Oracle 的会话模型和 shell 的进程模型存在三处隐性冲突事务边界失控SQL*Plus 默认每条语句自动 commit。如果你的模板删除涉及WIP_ENTITIES→WIP_OPERATIONS→WIP_REQUIREMENTS三级外键中间某条 DELETE 因触发器失败而中断前面已 commit 的记录无法回滚——这不是 bug是设计使然。错误码静默丢失sqlplus -S在遇到ORA-02292: integrity constraint violated时exit code 仍是 0。shell 脚本if [ $? -eq 0 ]; then echo success; fi会误判为成功。会话资源泄漏未显式DISCONNECT或EXIT的 SQL*Plus 子进程在高并发调用时可能残留ACTIVE状态会话撑爆processes参数。提示Oracle 官方文档明确建议对 DML 操作的自动化脚本必须使用WHENEVER SQLERROR EXIT SQL.SQLCODEWHENEVER OSERROR EXIT 9双保险机制。这不是最佳实践是强制要求。2.2 正确姿势用 SQL*Plus 的批处理模式 shell 的 exit code 映射核心逻辑是让 SQL*Plus 成为 shell 的严格协作者而非甩手掌柜。我们不追求“一行命令搞定”而要确保每个环节的 exit code 都可被捕获、可被解释、可被日志记录。#!/bin/bash # uninstall_template.sh —— Oracle 数据模板卸载主入口 set -e # 任何命令失败立即退出关键 set -u # 未定义变量报错防 $ORACLE_SID 写错成 $ORACLE_SDI set -o pipefail # 管道中任意命令失败即整体失败 # 1. 环境预检Oracle 客户端、TNS 配置、权限 if ! command -v sqlplus /dev/null 21; then echo [ERROR] sqlplus not found in PATH. Please check Oracle client installation. 2 exit 127 fi if [ ! -f $ORACLE_HOME/network/admin/tnsnames.ora ]; then echo [ERROR] tnsnames.ora missing at $ORACLE_HOME/network/admin/ 2 exit 1 fi # 2. 构建唯一执行 ID用于日志隔离与回滚定位 EXEC_ID$(date %Y%m%d_%H%M%S_${RANDOM:0:4}) LOG_DIR/var/log/oracle_template_uninstall mkdir -p $LOG_DIR LOG_FILE${LOG_DIR}/uninstall_${EXEC_ID}.log exec (tee -a $LOG_FILE) 21 echo [INFO] Start uninstall template with EXEC_ID: ${EXEC_ID} echo [INFO] Oracle environment: ORACLE_HOME${ORACLE_HOME}, ORACLE_SID${ORACLE_SID} # 3. 调用 SQL 脚本严格绑定 exit code sqlplus -S /nolog EOF SET ECHO OFF SET FEEDBACK OFF SET VERIFY OFF SET HEADING OFF SET PAGESIZE 0 -- 关键错误立即退出并返回 Oracle 错误码 WHENEVER SQLERROR EXIT SQL.SQLCODE WHENEVER OSERROR EXIT 9 -- 连接显式指定 TNS 别名避免依赖 TWO_TASK CONNECT ${DB_USER}/${DB_PASS}${DB_TNS_ALIAS} -- 开启事务控制 BEGIN -- 步骤1检查模板是否存在防重复执行 DECLARE v_count NUMBER; BEGIN SELECT COUNT(*) INTO v_count FROM wip_discrete_jobs WHERE attribute1 ${TEMPLATE_CODE} AND status_type 1; IF v_count 0 THEN RAISE_APPLICATION_ERROR(-20001, Template [ || ${TEMPLATE_CODE} || ] not found); END IF; END; -- 步骤2禁用相关触发器避免级联失败 EXECUTE IMMEDIATE ALTER TRIGGER wip_job_ins_trig DISABLE; -- 步骤3执行主模板删除带保存点 SAVEPOINT before_template_delete; DELETE FROM wip_discrete_jobs WHERE attribute1 ${TEMPLATE_CODE} AND status_type 1; -- 步骤4级联删除子项按依赖顺序 DELETE FROM wip_operations WHERE job_id IN (SELECT job_id FROM wip_discrete_jobs WHERE attribute1 ${TEMPLATE_CODE}); DELETE FROM wip_requirements WHERE operation_seq_num IN ( SELECT operation_seq_num FROM wip_operations WHERE job_id IN (SELECT job_id FROM wip_discrete_jobs WHERE attribute1 ${TEMPLATE_CODE})); -- 步骤5重新启用触发器 EXECUTE IMMEDIATE ALTER TRIGGER wip_job_ins_trig ENABLE; -- 步骤6提交 COMMIT; EXCEPTION WHEN OTHERS THEN ROLLBACK TO before_template_delete; RAISE; END; / EXIT SUCCESS EOF # 4. 捕获 SQL*Plus 的 exit code 并映射为语义化错误 SQLPLUS_EXIT_CODE$? case $SQLPLUS_EXIT_CODE in 0) echo [SUCCESS] Template ${TEMPLATE_CODE} uninstalled successfully. exit 0 ;; 1) echo [ERROR] SQL*Plus connection failed (invalid credentials or TNS). 2 exit 1 ;; 9) echo [ERROR] OS-level error in SQL*Plus (file permission, disk full). 2 exit 9 ;; 20001) echo [WARN] Template not found, nothing to uninstall. 2 exit 0 # 业务上允许不视为失败 ;; *) echo [ERROR] Oracle SQL error occurred: ORA-${SQLPLUS_EXIT_CODE} 2 # 尝试从日志提取最近 10 行 Oracle 错误堆栈 grep -A 5 -B 2 ORA- $LOG_FILE | tail -n 10 exit $SQLPLUS_EXIT_CODE ;; esac代码逻辑说明set -e -u -o pipefail是 shell 脚本健壮性的基石缺一不可。尤其pipefail防止grep | head类管道中上游失败却被下游掩盖。WHENEVER SQLERROR EXIT SQL.SQLCODE让 Oracle 错误码直接透传给 shellORA-00942→ exit code 942ORA-02292→ exit code 2292无需解析日志文本。SAVEPOINTROLLBACK TO实现事务内局部回滚比整个事务 rollback 更精准——比如触发器禁用失败不影响前面的检查逻辑。EXECUTE IMMEDIATE动态 SQL 绕过静态权限限制DBA 只需授予ALTER ANY TRIGGER无需开放wip_job_ins_trig的直接ALTER权限。参数说明必须由调用方注入DB_USER/DB_PASS专用卸载账号最小权限原则仅SELECT检查 DELETE主表 ALTER TRIGGER。DB_TNS_ALIASTNS 名称严禁使用//host:port/service_name字符串直连必须走tnsnames.ora解析保证网络层配置统一。TEMPLATE_CODE模板唯一标识来自attribute1字段必须做 SQL 注入防护本例中假设已由上游系统校验若需动态拼接必须用DBMS_ASSERT.ENQUOTE_LITERAL包处理。3. 模板元数据驱动把硬编码 SQL 变成可配置的 JSON 清单3.1 为什么要把表名、字段、条件写死在脚本里—— 一次改十套环境全崩EBS 环境里WIP_DISCRETE_JOBS表在 R12.2.9 中字段是ATTRIBUTE1到了 R12.2.10 可能变成ZD_ATTRIBUTE1PAC 成本模板在 19c 上存于CST_COST_ELEMENTS在 12c 可能还在CST_ELEMENTAL_COSTS。如果每个环境都维护一份独立脚本版本管理、灰度发布、回滚验证全是灾难。正确解法是把模板结构抽象成元数据脚本只负责解析和执行。我们定义一个template_manifest.json{ template_code: PAC_2024_Q3, description: Q3 标准成本模板含 BOMRoutingCosting, version: 1.2.0, tables: [ { table_name: WIP_DISCRETE_JOBS, key_column: ATTRIBUTE1, status_column: STATUS_TYPE, status_value: 1, dependency_order: 1, pre_sql: ALTER TRIGGER wip_job_ins_trig DISABLE, post_sql: ALTER TRIGGER wip_job_ins_trig ENABLE }, { table_name: WIP_OPERATIONS, key_column: JOB_ID, lookup_table: WIP_DISCRETE_JOBS, lookup_key: JOB_ID, dependency_order: 2, pre_sql: null, post_sql: null }, { table_name: WIP_REQUIREMENTS, key_column: OPERATION_SEQ_NUM, lookup_table: WIP_OPERATIONS, lookup_key: OPERATION_SEQ_NUM, dependency_order: 3, pre_sql: null, post_sql: null } ], archive: { enabled: true, target_dir: /backup/oracle_template_archive, compress: gzip } }3.2 用 jq sed 构建动态 SQL 生成器shell 本身不支持 JSON 解析但jq是事实标准。我们用它读取清单生成带依赖顺序的 SQL 块# generate_uninstall_sql.sh —— 根据 manifest 生成可执行 SQL #!/bin/bash MANIFEST$1 if [ ! -f $MANIFEST ]; then echo Manifest file $MANIFEST not found 2 exit 1 fi TEMPLATE_CODE$(jq -r .template_code $MANIFEST) ARCHIVE_DIR$(jq -r .archive.target_dir $MANIFEST) # 1. 生成备份 SQL先归档再删除 echo -- Step 0: Archive original data echo SPOOL ${ARCHIVE_DIR}/archive_${TEMPLATE_CODE}_$(date %Y%m%d).sql echo SET LINESIZE 32767 echo SET PAGESIZE 0 echo SET FEEDBACK OFF echo SET TRIMSPOOL ON # 2. 按 dependency_order 排序表生成 DELETE 语句 jq -s sort_by(.dependency_order)[] $MANIFEST | while read -r table_json; do TABLE_NAME$(echo $table_json | jq -r .table_name) KEY_COLUMN$(echo $table_json | jq -r .key_column) STATUS_COLUMN$(echo $table_json | jq -r .status_column // empty) STATUS_VALUE$(echo $table_json | jq -r .status_value // empty) # 构建 WHERE 条件 if [ -n $STATUS_COLUMN ] [ -n $STATUS_VALUE ]; then WHERE_CLAUSEWHERE ${KEY_COLUMN} ${TEMPLATE_CODE} AND ${STATUS_COLUMN} ${STATUS_VALUE} else WHERE_CLAUSEWHERE ${KEY_COLUMN} ${TEMPLATE_CODE} fi echo -- Delete from ${TABLE_NAME} echo SELECT DELETE FROM ${TABLE_NAME} ${WHERE_CLAUSE}; FROM DUAL; echo SELECT COMMIT; FROM DUAL; done | sed /^$/d /tmp/uninstall_steps.sql # 3. 注入 pre_sql / post_sql while IFS read -r line; do if [[ $line *DELETE FROM* ]]; then TABLE_NAME$(echo $line | sed -n s/DELETE FROM \([^ ]*\).*/\1/p) PRE_SQL$(jq -r --arg t $TABLE_NAME .tables[] | select(.table_name $t) | .pre_sql $MANIFEST) POST_SQL$(jq -r --arg t $TABLE_NAME .tables[] | select(.table_name $t) | .post_sql $MANIFEST) if [ $PRE_SQL ! null ]; then echo $PRE_SQL; fi echo $line if [ $POST_SQL ! null ]; then echo $POST_SQL; fi else echo $line fi done /tmp/uninstall_steps.sql /tmp/final_uninstall.sql echo [INFO] Generated uninstall SQL: /tmp/final_uninstall.sql关键点说明jq -s sort_by(.dependency_order)[]确保表按依赖顺序处理避免外键冲突。sed -n s/DELETE FROM \([^ ]*\).*/\1/p提取表名用于匹配pre_sql这是 shell 处理 JSON 的典型技巧——用jq提取结构用sed/awk做字符串微调。归档 SQL 用SPOOL生成不是INSERT INTO backup_table SELECT *因为备份目标可能是不同数据库或文件系统SPOOL输出纯 SQL 最灵活。4. 避坑DBA 和运维最常踩的 5 个血泪现场4.1 现象脚本执行成功但第二天发现 WIP 工单状态异常原因未禁用WIP_JOB_STATUS_TRG触发器该触发器在DELETE FROM WIP_DISCRETE_JOBS后自动向WIP_JOB_STATUS_LOG插入状态变更记录而该表有NOT NULL字段未被填充导致触发器内部INSERT失败但因WHENEVER SQLERROR未覆盖触发器上下文错误被静默吞掉。解决在pre_sql中显式DISABLE所有涉及目标表的触发器并在post_sql中ENABLE。用SELECT trigger_name FROM all_triggers WHERE table_name WIP_DISCRETE_JOBS AND status ENABLED提前扫描写入 manifest。4.2 现象在 RAC 环境下脚本有时成功有时失败错误码随机原因sqlplus -S /nolog默认连接到本地实例但 RAC 的tnsnames.ora别名可能配置了LOAD_BALANCEon导致连接漂移。当DELETE执行到一半会话被重定向到另一节点SAVEPOINT失效。解决在tnsnames.ora中为卸载专用别名添加(FAILOVER_MODE(TYPENONE))或在连接字符串中强制指定INSTANCE_NAMECONNECT user/passDB_ALIAS_INSTANCE1。4.3 现象TEMPLATE_CODE包含单引号脚本直接报语法错误原因attribute1 ${TEMPLATE_CODE}直接拼接TEMPLATE_CODEOCONNOR导致 SQL 变成attribute1 OCONNOR。解决绝不允许 shell 变量直插 SQL。改用 Oracle 绑定变量在 SQL*Plus 中DEFINE template_code 1调用时sqlplus -S /nolog uninstall.sql ${TEMPLATE_CODE}SQL 内用template_code。或更彻底——用DBMS_ASSERT.ENQUOTE_LITERAL在 PL/SQL 块内处理。4.4 现象归档目录/backup/oracle_template_archive空间不足脚本却显示 success原因SPOOL到文件时磁盘满导致sqlplus进程被SIGPIPE终止但sqlplusexit code 为 141非 0而脚本未捕获此码。解决在generate_uninstall_sql.sh开头加入空间检查ARCHIVE_DIR$(jq -r .archive.target_dir $MANIFEST) REQUIRED_SPACE$(( $(stat -c %s $MANIFEST) * 10 )) # 估算 10 倍放大 AVAILABLE_SPACE$(df $ARCHIVE_DIR | awk NR2 {print $4}) if [ $AVAILABLE_SPACE -lt $REQUIRED_SPACE ]; then echo [ERROR] Insufficient space in $ARCHIVE_DIR: need ${REQUIRED_SPACE}KB, available ${AVAILABLE_SPACE}KB 2 exit 100 fi4.5 现象多个运维同事同时执行同一模板卸载数据被删两次原因脚本无并发控制两个进程同时SELECT COUNT(*)返回 1都进入删除流程。解决在 SQL 块开头加分布式锁DECLARE v_lock_handle VARCHAR2(128); BEGIN DBMS_LOCK.ALLOCATE_UNIQUE( lockname UNINSTALL_TEMPLATE_ || ${TEMPLATE_CODE}, lockhandle v_lock_handle ); IF DBMS_LOCK.REQUEST( lockhandle v_lock_handle, lockmode DBMS_LOCK.X_MODE, timeout 0, -- 立即失败不等待 release_on_commit TRUE ) ! 0 THEN RAISE_APPLICATION_ERROR(-20002, Another uninstall process is running for template || ${TEMPLATE_CODE}); END IF; END; /5. 生产验证三步法确认卸载真正完成不是“看起来删了”5.1 第一步用DBA_TAB_MODIFICATIONS验证物理删除Oracle 不会立刻清除数据块DELETE后记录仍在DBA_TAB_MODIFICATIONS中标记为INSERTS/UPDATES/DELETES。真正的删除完成是DELETES计数归零且FLUSH_DATABASE_MONITORING_INFO已执行-- 在卸载脚本最后追加验证 SQL BEGIN DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO; END; / SELECT table_name, inserts, updates, deletes, truncated FROM dba_tab_modifications WHERE table_name IN (WIP_DISCRETE_JOBS, WIP_OPERATIONS, WIP_REQUIREMENTS) AND deletes 0;如果返回空集说明DELETE已提交且监控信息已刷新。若仍有记录说明事务未真正提交常见于COMMIT被注释或ROLLBACK未被拦截。5.2 第二步用DBA_HIST_ACTIVE_SESS_HISTORY追踪会话行为当 DBA 怀疑“脚本说删了但数据还在”不要查SELECT COUNT(*)直接查历史会话SELECT sample_time, sql_id, sql_text, event, wait_class FROM dba_hist_active_sess_history a JOIN dba_hist_sqltext s ON a.sql_id s.sql_id WHERE sample_time SYSDATE - 1/24 -- 过去1小时 AND sql_text LIKE %WIP_DISCRETE_JOBS% AND sql_text NOT LIKE %SELECT% ORDER BY sample_time DESC;看sql_text是否真执行了DELETEevent是否卡在enq: TX - row lock contention说明有未提交事务wait_class是否为Idle说明 SQL 已结束。5.3 第三步用RMAN验证归档完整性针对开启归档的生产库如果archive.enabledtrue必须验证归档是否真实写入# 在 shell 脚本末尾执行 ARCHIVE_LOG_DEST$(sqlplus -S / as sysdba EOF SET PAGES 0 FEED OFF VER OFF SELECT value FROM v\$parameter WHERE name log_archive_dest_1; EXIT EOF ) # 检查归档目录下是否有本次卸载时间窗口的日志 ARCHIVE_TIME$(date -d -5 minutes %Y_%m_%d) if ls ${ARCHIVE_LOG_DEST%/}/$ARCHIVE_TIME* 1/dev/null 21; then echo [VERIFY] Archive logs generated for uninstall window. else echo [ALERT] No archive logs found. Check ARCHIVE_LAG_TARGET parameter. 2 exit 101 fi注意V$PARAMETER查询必须用sysdba普通用户无权访问。此处用sqlplus -S / as sysdba要求脚本运行账号具备OSDBA组权限这是生产环境的标准配置。6. 我的私藏技巧用strace抓住 Oracle 客户端的真实行为所有理论都敌不过一次真实抓包。当你遇到“脚本在测试环境 OK生产环境失败错误码却是 0”别急着改 SQL——先用strace看sqlplus真正在做什么# 在生产服务器上用 strace 监控 sqlplus 调用 strace -f -e traceopen,connect,write,read -s 200 -o /tmp/sqlplus_trace.log \ sqlplus -S /nolog EOF CONNECT user/passPROD_DB SELECT * FROM dual; EXIT EOF然后搜索关键线索open(/u01/app/oracle/product/19c/dbhome_1/network/admin/tnsnames.ora, O_RDONLY)→ 确认读取的是哪个tnsnames.oraconnect(12, {sa_familyAF_INET, sin_porthtons(1521), sin_addrinet_addr(10.1.2.3)}, 16)→ 确认连的是哪个 IP排除 DNS 缓存问题write(12, DELETE FROM WIP_DISCRETE_JOBS WHERE ATTRIBUTE1 PAC_2024_Q3;\n, 62)→ 确认发送的 SQL 完全正确无隐藏字符我曾靠这一招发现测试环境tnsnames.ora里PROD_DB指向10.1.1.1生产环境同名别名却指向10.1.1.1:1522监听端口被运维悄悄改了而sqlplus连接超时后静默返回 0。strace里connect()系统调用失败但sqlplus进程没退出——这就是WHENEVER OSERROR EXIT 9的价值它让 shell 知道底层网络失败了。最后提醒一句永远在uninstall_template.sh里留一个--dry-run模式开关。不是用echo模拟而是真连接、真查询、真生成归档 SQL但把DELETE替换为SELECT COUNT(*)把COMMIT替换为ROLLBACK。上线前./uninstall_template.sh --dry-run -t PAC_2024_Q3必须跑通且日志里明确写出“[DRY RUN] Would delete 37 rows from WIP_DISCRETE_JOBS”。这才是对生产环境最基本的敬畏。希望帮到你。本文还有配套的精品资源点击获取