2. 程式人生 > >impdp因致命錯誤終止 ORA-7445 [kpodpals]

impdp因致命錯誤終止 ORA-7445 [kpodpals]

阿新 • • 發佈：2017-05-12
epm esp fcm 項目 ops sdn alert tool upm

基本要素 前天好不easy成功給用戶把數據全庫導出，今天用戶又告知導出的數據無法導入，首先就問用戶有什麽錯誤提示，給我的回答是就一個‘作業"SYSTEM"."SYS_IMPORT_FULL_03" 因致命錯誤於 xxxx elapsed 0 03:01:06 停止’,其它什麽提示都沒有，信息量太少了，這個處理起來還挺麻煩的。

 問題分析

步驟一：首先還是加入跟蹤信息 還是得靠自己，還好咱們會點跟蹤技巧，詳細方法見我之前的帖How to Diagnose Oracle Data Pump-怎樣給數據泵加入診斷信息，來吧，看下跟蹤後的結果orcl_dm00_10856.trc，錯誤提示的位置例如以下：
KUPM:13:38:03.378: Log message received from worker DG,KUPC$C_1_20141208103757,KUPC$A_1_103800203000000,MCP,510,Y KUPM:13:38:03.378: . . 導入了 "ZLHIS"."體檢套餐計價" 576.4 KB 20817 行 KUPM:13:38:03.378: ****OUT DISPATCH, request type=3031, response type =2041 *** 2014-12-08 13:38:04.392 KUPM:13:38:04.392: Client count is: 1
KUPM:13:38:04.392: In check_workers... KUPM:13:38:04.392: Live worker count is: 1 KUPM:13:38:04.392: In set_longops KUPM:13:38:04.392: Work so far is: 107805.74195098876953125 KUPM:13:38:04.392: Checking for resumable waits KUPM:13:39:05.435: Client count is: 1 *** 2014-12-08 13:39:05.435 KUPM:13:39:05.435: In check_workers...
KUPM:13:39:05.435: Live worker count is: 0 KUPM:13:39:05.435: worker id is: KUPM:13:39:05.435: Worker error is: 0 KUPM:13:39:05.435: Exited main loop... KUPM:13:39:05.435: Returned to MAIN KUPV:13:39:05.435: Update request for job: SYSTEM.SYS_IMPORT_FULL_03, func: 1 KUPM:13:39:05.435: Entered state: STOPPING KUPM:13:39:05.435: keeping master because job is restartable KUPM:13:39:05.435: Final job_info_flags = 1 KUPM:13:39:05.435: Log message received from MCP KUPM:13:39:05.435: 作業 "SYSTEM"."SYS_IMPORT_FULL_03" 因致命錯誤於 星期一 12月 8 13:39:05 2014 elapsed 0 03:01:06 停止 KUPM:13:39:05.498: In RESPOND_TO_START KUPM:13:39:05.498: In check_workers... KUPM:13:39:05.498: Live worker count is: 0 KUPM:13:39:05.498: worker id is: KUPM:13:39:05.498: Worker error is: 0 結果很令人失望，也沒什麽有價值的錯誤提示。

 步驟二：查看下alert日誌 這時候想到查看下alert日誌，或許裏面能給一些提示，打開日誌果然發現了很有價值的信息，例如以下： Tue Dec 09 02:00:00 2014 Closing scheduler window Closing Resource Manager plan via scheduler window Clearing Resource Manager plan via parameter Tue Dec 09 02:00:12 2014 Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x0] [PC:0x14575B408, kpodpals()+5174] ERROR: Unable to normalize symbol name for the following short stack (at offset 213): dbgexProcessError()+200<-dbgeExecuteForError()+65<-dbgePostErrorKGE()+2269<-dbkePostKGE_kgsf()+77<-kgeade()+562<-kgerelv()+151<-kgerev()+45<-kgerec5()+60<-sss_xcpt_EvalFilterEx()+1862<-sss_xcpt_EvalFilter()+174<-.1.4_5+59<-0000000077C985A8<-0000000077CA9D0D<-0000000077C991AF<-0000000077CD1278<-kpodpals()+5174<-kpodpp()+4946<-opiodr()+1631<-kpoodr()+699<-xupirtrc()+2833<-upirtrc()+117<-kpurcsc()+150<-kpudpxp_ctxPrepare()+19418<-OCIDirPathPrepare()+11<-kupd_initDirPath()+1048<-kupdls()+2863<-spefcifa()+3937<-spefmccallstd()+532<-pextproc()+47<-PGOSF493_peftrusted()+134<-psdexsp()+297<-rpiswu2()+3039<-psdextp()+951<-pefccal()+785<-pefcal()+225<-pevm_FCAL()+164<-pfrinstr_FCAL()+69<-pfrrun_no_tool()+77<-pfrrun()+1241<-plsql_run()+903<-peicnt()+328<-kkxexe()+616<-opiexe()+20959<-kpoal8()+2397<-opiodr()+1631<-kpoodr()+699<-xupirtrc()+2833<-upirtrc()+117<-kpurcsc()+150<-kpuexec()+10984 Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dw00_5304.trc (incident=8636): ORA-07445: 出現異常錯誤: 核心轉儲 [kpodpals()+5174] [ACCESS_VIOLATION] [ADDR:0x0] [PC:0x14575B408] [UNABLE_TO_READ] [] Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\incident\incdir_8636\orcl_dw00_5304_i8636.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Tue Dec 09 02:00:17 2014 Dumping diagnostic data in directory=[cdmp_20141209020017], requested by (instance=1, osid=5304 (DW00)), summary=[incident=8636]. Tue Dec 09 02:00:19 2014 Sweep [inc][8636]: completed Sweep [inc2][8636]: completed Tue Dec 09 02:00:55 2014 有了這個信息。更進一步的日誌分析我這裏就不再敘述。由於也沒什麽價值信息，我們這裏就抓住ORA-07445 [kpodpals()+5174]不放。這樣的核心錯誤，一般99%是Oracle的BUG引起，通過Oracle的官方信息。果然發現了一篇文檔： ORA-7445 [kpodpals] During DataPump Import (文檔 ID 1096837.1) SYMPTOMS
You perform a DataPump import and this breaks with errors: #> impdp system/password directory=dpu dumpfile=a_table.dmp table_exists_action=replace Import: Release 10.2.0.1.0 - Production on Wednesday, 21 April, 2010 9:21:43
Copyright (c) 2003, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded
Starting "SYSTEM"."SYS_IMPORT_FULL_01": system/******** directory=dpu
dumpfile=a_table.dmp table_exists_action=replace
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
ORA-39014: One or more workers have prematurely exited.
ORA-39029: worker 1 with process name "DW01" prematurely terminated
ORA-31672: Worker process DW01 died unexpectedly.
Job "SYSTEM"."SYS_IMPORT_FULL_01" stopped due to fatal error at 09:23:32 CAUSE
This is addressed in Bug 9626756. A no-name column "<space>" is included in the table definition.
The imported table is defined as: create table a_table
(
id number,
" " varchar2(10), -- " " means "<one space>"
text varchar2(10)
); SOLUTION
1. Don‘t use columns like "<space>" in the source database

- OR -

2. If a table has such columns, then exclude the table during import with: exclude=table:\"IN (‘A_TABLE‘)\" 原因就是有表的字段是空格。坑爹啊，竟然有這麽創建表的，接下來我們就要查詢下我們系統中是否真的存在這種表。 解決過程

步驟一：查詢表字段 技術分享
 通過上門的SQL語句，一查詢果然有有空字段，表名是TX_診療項目。該表不是我們系統帶的表，是因為之前渠道做系統切換的時候，保存的用戶舊系統數據的表，真是害死人啊。

 步驟二：排除表又一次導入 有兩種方式解決，1.在正式庫中對表進行調整或者重建，2.導入的時排除問題表。經過溝通決定採用另外一種方法。排除表 impdp system/xxxxx DIRECTORY=dp full=y DUMPFILE=wzyfull20141205b_01.dmp logfile=impdp1209.log trace=4a0300 exclude=TABLE:\"IN \(\‘ZLHIS.TX_診療項目\‘\)\",SCHEMA:\"IN\(\‘SYS\‘,\‘SYSTEM\‘,\‘OUTLN\‘,\‘MGMT_VIEW\‘,\‘FLOWS_FILES\‘,\‘MDSYS\‘,\‘ORDSYS\‘,\‘EXFSYS\‘,\‘DBSNMP\‘,\‘WMSYS\‘,\‘WKSYS\‘,\‘WK_TEST\‘,\‘CTXSYS\‘,\‘ANONYMOUS\‘,\‘SYSMAN\‘,\‘XDB\‘,\‘WKPROXY\‘,\‘ORDPLUGINS\‘,\‘FLOWS_030000\‘,\‘OWBSYS\‘,\‘SI_INFORMTN_SCHEMA\‘,\‘OLAPSYS\‘,\‘SCOTT\‘,\‘ORACLE_OCM\‘\)\" 經過3個多小時的漫長等待。數據成功導入。 關鍵知識點 數據泵日誌跟蹤：通過在導出導入時。加入trace參數，產生跟蹤日誌文件 ORA-7445 [kpodpals]： Bug 9626756.在一個表中包括一個沒有名字的全是空格的字段

impdp因致命錯誤終止 ORA-7445 [kpodpals]

相關推薦

impdp因致命錯誤終止 ORA-7445 [kpodpals]

epm esp fcm 項目 ops sdn alert tool upm 基本要素 前天好不easy成功給用戶把數據全庫導出，今天用戶又告知導出的數據無法導入，首先就問用戶有什麽錯誤提示，給我的回答是就一個‘作業"SYSTEM"."SYS_IMPORT_FULL_0

關於 IMPDP 匯入問題 ，關於ora-39125 錯誤 “物件已存在” 的解決

用資料泵匯入資料庫效率很高，但是需要了解一點點東西 下面用個例子來說明 impdp tbzh_xxx/tbzh_xxx  DIRECTORY=DUMP  logfile=import.log DUMPFILE=tbzh_data-bak.dmp REMAP_SCH

記一次impdp匯入資料時的ORA-31696錯誤

今天幫一同事從一個dump檔案中匯入資料到測試庫中，結果死活出現ORA-31696的錯誤： [[email protected]]$ impdp pebank/pebank directory=dumpdir dumpfile=mcj123.1011.dmp

weblogic10.3 選擇域源後報錯：出現致命錯誤。此應用程式將終止。解決方法。

可能是我係統有問題，最可能有問題的是我的人品吧。不過更可能出問題的應該是我係統吧。同樣的weblogic10.3，同事安裝配置域都沒有問題，到我這裡報錯：出現致命錯誤。此應用程式將終止。如下圖：然後作為一個碼農除了心態開始崩，然後各種百度，bing，搜狗都搜了也沒有找到解決辦

oracle通過exp匯出dump，報錯報錯，EXP-00008: 遇到 ORACLE 錯誤 90 ORA-00904: "POLTYP": 識別符號無效 EXP-00000: 匯出終止失敗

EXP-00008: 遇到 ORACLE 錯誤 90 ORA-00904: "POLTYP": 識別符號無效EXP-00000: 匯出終止失敗 原因：exp工具是高版本的（如11g），而被匯出的資料庫時低版本的（10g），這樣，匯出就有問題。 怎麼檢視oracle版本？ 1

如果你是第一次創業，一定要避免犯這6個致命錯誤

開會 ron 最終 筆記 深入 創業公司 什麽是 src 即使 打造一家成功的創業公司太不容易。很多創業者都是在經歷了幾次失敗的創業之後才最終打造了一家實現規模化發展的盈利公司。之所以會這樣，部分原因是因為初次創業者經常會犯一些嚴重危害公司發展的重大錯誤。 有數據統計，超

zmalloc.h:50:31: 致命錯誤：jemalloc/jemalloc.h：沒有那個文件或目

dep file tro from n) htm dev chm -a 我報錯是這樣子的，然後老師打了一條命令[root@WEB redis-3.0.6]# makecd src && make allmake[1]: 進入目錄“/root/lnmp_sof

硬盤提示無法訪問設備硬件出現致命錯誤,導致請求失敗，裏面的數據如何找到

無法 重要 aurora 找到 OS 直接 http AD 軟件圖標 設備硬件出現致命錯誤,導致請求失敗說明這個盤的文件系統結構損壞了。在平時如果數據不重要，那麽可以直接格式化就能用了。但是有的時候裏面的數據很重要，那麽就必須先恢復出數據再格式化。具體恢復方法可以看正文了解

無法訪問移動磁盤顯示設備硬件出現致命錯誤,導致請求失敗的數據找到法子

選擇 數據恢復軟件 正文 註意 http 無法 搜索 百度 保存 移動硬盤打不開設備硬件出現致命錯誤,導致請求失敗，是因為這個I盤的文件系統內部結構損壞導致的。要恢復裏面的數據就必須要註意，這個盤不能格式化，否則數據會進一步損壞。具體的恢復方法看正文 工具/軟件：流星數據

PostgreSQL遠程連接配置管理/賬號密碼分配（解決：致命錯誤: 用戶 "postgres" Ident 認證失敗）

切換用戶 pri reject bsp 拒絕 linu 創建用戶 code psql 問題：致命錯誤: 用戶 "postgres" Ident 認證失敗 說明：這個是由於沒有配置遠程訪問且認證方式沒改造成的，只需要更改使用賬號密碼認證即可。 解決：找到pg_hba.co

移動硬盤顯示設備硬件出現致命錯誤,導致請求失敗的數據尋回法子

數據恢復無法訪問文件恢復數據找回 移動硬盤打不開設備硬件出現致命錯誤,導致請求失敗，是因為這個I盤的文件系統內部結構損壞導致的。要恢復裏面的數據就必須要註意，這個盤不能格式化，否則數據會進一步損壞。具體的恢復方法看正文工具/軟件：星空數據恢復軟件步驟1：先下載並解壓程序打開後，直接雙擊需要恢復的分區，接

無法訪問K盤提示設備硬件出現致命錯誤,導致請求失敗的文件恢復方案

工具 無法訪問 如果 但是 文件 ima 下載 文件系統 以管理員身份運行 設備硬件出現致命錯誤,導致請求失敗說明這個盤的文件系統結構損壞了。在平時如果數據不重要，那麽可以直接格式化就能用了。但是有的時候裏面的數據很重要，那麽就必須先恢復出數據再格式化。具體恢復方法可以看正

F盤顯示設備硬件出現致命錯誤,導致請求失敗要怎樣辦啊

出現 雙擊 其它 分享圖片 9.png 失敗 導致 proc blog 移動磁盤磁盤未被格式化的文件尋回方案 設備硬件出現致命錯誤,導致請求失敗說明這個盤的文件系統結構損壞了。在平時如果數據不重要，那麽可以直接格式化就能用了。但是有的時候裏面的數據很重要，那麽就必須先

硬盤顯示無法訪問設備硬件出現致命錯誤,導致請求失敗，裏面的文件怎樣尋回

process b2b col ESS 百度 roc 雙擊 ges 資料 F盤打不開設備硬件出現致命錯誤,導致請求失敗，是因為這個I盤的文件系統內部結構損壞導致的。要恢復裏面的數據就必須要註意，這個盤不能格式化，否則數據會進一步損壞。具體的恢復方法看正文 工具/軟件：流星數

.NET 通過entity framework報數據庫連接錯誤：ORA-01017: invalid username/password; logon denied

ces lse rac string lec oca policy system 得到 如題，答案為：【ORA-01017】.NET程序連接數據庫失敗 轉載文章內容如下： 遇到問題 使用 C#/.NET 開發的一個客戶端程序，需要連接 ORACLE 數據庫，使用 O

JVM致命錯誤日誌(hs_err_pid.log)分析

nco ots 堆棧 升級 boot 原因 enc 崩潰原因 minor 當jvm出現致命錯誤時，會生成一個錯誤文件 hs_err_pid<pid>.log，其中包括了導致jvm crash的重要信息，可以通過分析該文件定位到導致crash的根源，從而改善以保證

建立表空間時出現錯誤：ORA-27040以及開啟監聽服務時提示網路協議介面卡錯誤。

今天做oracle資料庫建立表空間的操作，一直提示ORA-27040,OSD -04002，O/s-Error(os 3)錯誤。 檢查了建立的語句是沒有問題的，刪除重建發現建立過程也是正確了，管理員方式執行SQLplus也不行，最後經過查詢和驗證才發現是我電腦許可權的問題（用的管理員許可

【oracle報錯】 impdp匯入資料報錯ORA-29283: invalid file operation

oracle impdp匯入資料報錯ORA-29283: invalid file operation 資料庫版本：11.2.0.4；系統版本：Oracle Linux 6.4 場景： 使用impdp匯入資料，dump檔名為bop_1112.dump，directory為：dataBac

磁碟裝置硬體出現致命錯誤,導致請求失敗的資料找到辦法

    裝置硬體出現致命錯誤,導致請求失敗說明這個盤的檔案系統結構損壞了。在平時如果資料不重要，那麼可以直接格式化就能用了。但是有的時候裡面的資料很重要，那麼就必須先恢復出資料再格式化。具體恢復方法可以看正文了解（不格式化的恢復方法） 工具/軟體：AuroraDataR

win8.1 更新後出現致命錯誤C0000034，無法進入安全模式和高階選項

win8.1 更新後出現致命錯誤C0000034，無法進入安全模式和高階選項 昨天晚上回去時電腦強制更新了，只有睡眠，更新並重啟，更新並關機三個選項，坑的一批。點選更新後今早過來電腦就出現“錯誤 C0000034 …”,電腦無法啟動，百度說是在更新過程出現中斷引起。。而我只想知道怎麼解決