Re: Killing parallel processes?

From: Rich J <>
Date: Thu, 19 Mar 2020 16:22:42 -0500
Message-ID: <>

As a followup, after* a lot more* digging and then verifying that there were no parallel processes being used (via V$PX_PROCESS / V$PX_SESSION), the offending processes were sniped from the OS using:

lsof -K 9 /mnt/point/.nfs*

This was doable ONLY because nothing else was using that NFS mount. We verified that the old parallel processes were gone and that Oracle had respawned ones in their place. The mount point was then able to be unmounted.


p.s. Perhaps SIGTERM should have been used instead of SIGKILL, but that's for another discussion...

On Thu, Mar 19, 2020 at 10:28 AM Rich J <> wrote:

> Hey Andrew,
> Good call on the expdp process! I hadn't thought to check that. Now I
> just need to get the approvals and the killing can begin... :)
> Thanks!
> Rich
> On Thu, Mar 19, 2020 at 10:03 AM Andrew Kerber <>
> wrote:
>> You can safely kill the parallel processes, but make sure you know the
>> correct OS pid as well as the sid and serial# before you kill them, you
>> might need to kill them at both the database and OS level, and its hard to
>> find all of that after you kill them in one place. You should probably
>> make sure the expdp process has been completely killed first however.
>> On Thu, Mar 19, 2020 at 9:58 AM Rich J <> wrote:
>>> Hey all,
>>> In on AIX 7.1, I needed to export a few schemas that were
>>> larger than the local disk space available. Since on-the-fly compression
>>> is no longer feasible without Advanced Compression, I used an NSFv4 mount
>>> point.
>>> There was some issue (I don't recall -- it was in January) that I needed
>>> to kill the expdp. Ran it again with no problems, and all's well until
>>> today when I saw that the NFS mount point was still up and I tried to
>>> umount it. There are 7 files still open on the remote server from each of
>>> 7 parallel processes on the local database server. The files are named
>>> ".nfsxxxxx". I'd like to close this mount point, so I see that I have a
>>> few options:
>>> 1) Kill each parallel process. This database does not normally utilize
>>> parallel during the day, with only 1 query using it over night.
>>> 2) Bounce the instance. Scheduled downtime is in 6 days (just missed
>>> yesterday's window). This is a primary in an Active DG config with 1
>>> physical standby.
>>> 3) Stop the NFS client. Nothing else is using it.
>>> 4) Stop the NFS server. Nothing else is using it.
>>> The safest to me seems to be the instance bounce. But it's the most
>>> work, too, as I need to involve application folks.
>>> I've killed parallel processes before, but only on test instances where
>>> I didn't care what the outcome was. There's currently 64 parallel
>>> processes (the maximum for this instance, IIRC).
>>> Stopping NFS seems...messy. Unsure how the parallel processes will
>>> handle that.
>>> Thoughts?
>>> Thanks,
>>> Rich
>> --
>> Andrew W. Kerber
>> 'If at first you dont succeed, dont take up skydiving.'

Received on Thu Mar 19 2020 - 22:22:42 CET

Original text of this message