1、背景信息

客户这边使用数据泵迁移数据库，环境是 Centos7、Oracle11G，但是一直报错 ORA-31626:job does not exist。希望能让我看一眼。

2、操作报错

2.1导出控制变量法来定位报错

我接手以后也没多想，以为是数据库的用户的问题，于是我接着用控制变量法，

用系统用户去导出这个用户，不成功；

expdp \' / as sysdba \' schemas=AA dumpfile=AA_$(date +%Y%m%d).dmp directory=cwbak logfile=AA_$(date +%Y%m%d).log parallel=4 exclude=statistics;

 ORA-31626:job does not exist 失败。

用新建用户赋予dba权限导出用户，不成功；

create user test identified by test;
grant connect,resource,dba to test;
grant read,write on directory cwbak to test;
expdp test/test  schemas=AA  dumpfile=AA_$(date +%Y%m%d).dmp directory=cwbak logfile=AA_$(date +%Y%m%d).log parallel=4 exclude=statistics;

 ORA-31626:job does not exist 失败。

用系统用户和新创建用户导出别的用户，不成功

expdp \' / as sysdba \' schemas=BB dumpfile=BB_$(date +%Y%m%d).dmp directory=cwbak logfile=BB_$(date +%Y%m%d).log parallel=4 exclude=statistics;

expdp test/test schemas=BB dumpfile=BB_$(date +%Y%m%d).dmp directory=cwbak logfile=BB_$(date +%Y%m%d).log parallel=4 exclude=statistics;

ORA-31626:job does not exist 失败。

发现crontab定时任务，尝试用里边的语句

expdp \' / as sysdba \' schemas=CC,DD  dumpfile=CCDD_$(date +%Y%m%d).dmp directory=cwbak logfile=CCDD_$(date +%Y%m%d).log;

ORA-31626:job does not exist 失败。

  查询数据库备份路径里的信息，有个好消息是，这个设置备份的同事只定时删除了dmp文件，而log日志还在保留着，根据日志文件的大小进行区别，发现最后一个备份正常的日志，在一月八号，从那以后的备份都失败了，然后和业务沟通，说是一月八号有业务表方面的操作，但是对于数据库和系统表没有操作。（开发和实施的哥们就算有这些异常操作，既不会识别也不会说的）。

2.2清理数据库表空间

  开始对数据库进行检查和操作。

select a.tablespace_name,
       round(a.bytes / 1024 / 1024 /  1024, 0) "sum G",
       round((a.bytes - b.bytes) / 1024 /  1024 / 1024, 0) "used G",
       round(b.bytes / 1024 / 1024 /  1024, 0) "free G",
       round(((a.bytes - b.bytes) /  a.bytes) * 100, 2) "used%"
  from (select tablespace_name,  sum(bytes) bytes
          from dba_data_files
         group by tablespace_name) a,
       (select tablespace_name,  sum(bytes) bytes, max(bytes) largest
          from dba_free_space
         group by tablespace_name) b
where a.tablespace_name =  b.tablespace_name
order by ((a.bytes - b.bytes) / a.bytes)  desc;

但是发现太慢了，超过五分钟没查出来，很快就意识到可能是回收站有问题。

检查数据库的回收站

show parameter recyclebin;

select count(*) from dba_recyclebin;

purge dba_recyclebin;

再次查询表空间，发现system表空间使用率84%，其实不算太高。发现有大量的导出失败记录表，也进行删除。大概接近100多张失败表

select 'drop table '||OWNER_NAME||'.'||JOB_NAME||' purge;' from dba_datapump_jobs where STATE='NOT RUNNING';

2.3.定位数据库后台进程ora_dm

接着检查数据库的进程 ora_dm，看看有没有还在执行导致锁住的。

ps -ef| grep ora_dm

发现是没有进程，所以其实不是因为数据泵锁而导致的失败。

之所以检查这个进程，是每当你数据泵的时候，你会发现后台alert报警日志有这样的启动

Sat Apr 27 01:00:01 2024
DM00 started with pid=80, OS id=17017, job SYSTEM.SYS_EXPORT_SCHEMA_01
Sat Apr 27 01:00:02 2024
DW00 started with pid=87, OS id=17019, wid=1, job SYSTEM.SYS_EXPORT_SCHEMA_01

DMnn和DWnn(数据泵主进程/工作进程)

DM00是Data Pump Master Process

The Data Pump master (control) process is started during job creation and coordinates all tasks performed by the Data Pump job. It handles all client interactions and communication, establishes all job contexts, and coordinates all worker process activities on behalf of the job.

数据泵主（控制）过程在作业创建期间启动，并协调数据泵作业执行的所有任务。 它处理所有客户端交互和通信，建立所有作业上下文，并代表作业协调所有工作进程活动。

DW00是Data Pump Worker Process

The Data Pump worker process is responsible for performing tasks that are assigned by the Data Pump master process, such as the loading and unloading of metadata and data.

Data Pump工作进程负责执行由Data Pump主进程分配的任务，例如元数据和数据的加载和卸载。

其实这个时候已经没有办法了，控制变量导出、清理导出失败的表、查询导出进程的锁进程，可是还是没有头绪。

3、问题定位

富贵大佬帮忙百度到一篇文章说是qmnc的进程问题。

查看后台alert报警日志

Restaring dead backupgroup process QMNC
重新启动失效的备份组进程QMNC

透漏以下信息，一个是有这么一个进程在负责备份，另一个就是这个进程挂了，而且重启失败

查找这个进程没找到

[root@recovery_db:/root]# ps -ef | grep qmnc
root     32610 32554  0 21:30 pts/1    00:00:00 grep --color=auto qmnc

查找官方文档介绍

QMNC负责促进AQ和Oracle Streams所需的各种后台活动:消息的时间管理、非持久性队列的管理、资源的清理等等。QMNC根据执行这些任务的需要动态地生成Qnnn进程。

注意，如果AQ_TM_PROCESSES初始化参数设置为0，则该进程将不会启动。数据库将以下消息写入警报日志:WARNING: AQ_TM_PROCESSES设置为0。可能对系统造成不良影响。

Qnnn作为QMNC的从进程，执行QMNC分配的任务。这些进程的数量由QMNC根据负载动态管理。

Jnnn:作业从属进程由作业协调器在执行作业时创建或唤醒。

作业从服务器从数据字典中收集运行作业所需的所有元数据。从进程作为作业的所有者启动数据库会话，执行触发器，然后执行作业。作业完成后，从进程提交，然后执行适当的触发器并关闭会话。如果需要运行其他作业，从属服务器可以重复此操作。

查找对应的数据库参数

SQL> show parameter aq_tm_processes
NAME				              TYPE			       VALUE
----------------  ----------------  ------------------------------
aq_tm_processes 		     integer			       1

发现数据库参数其实是正常的，但是还是不行

4、问题解决

重新调整数据库参数

SQL> alter system set aq_tm_processes=0 scope=both;

SQL> alter system set aq_tm_processes=1 scope=both;

SQL> show parameter aq_tm_processes

NAME TYPE VALUE
------------------------------------ --------------------------------- ------------------------------
aq_tm_processes integer 1

结果数据库进程 ora_qmnc_orcl 还是没找到，只能重启数据库试试了。

重启是万能的，当然成功了！

5、事后感想

其实这次处理问题还是属于有杆子没杆子搂一下，有个群的群友就是在说，我不知道我什么能解决，但我就是把它解决了。就是学到了术（技术、方法）却没有学到道（原理、根源）。

在此重新排序一下我的解决步骤。

1、通过报错尝试不同的导出办法来尝试判断问题。

2、通过以往的经验来处理记录导出失败的表，来释放空间并尝试定位问题。

3、通过检查过往的导出历史记录来判断查找是否有成功的记录，并尝试解决这个问题。

4、查找数据库后台进程ora_dm来查找是否有堵塞的记录。

5、查找数据库后台alert报警日志来查找是否有价值的信息，并据此来百度或问群友。

  感叹一声，O的生态还是真棒，什么问题都能查到，难点就是如何判断和甄选。