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.
Thanks!
Rich
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 <rich242j@xxxxxxxxx> 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 <andrew.kerber@xxxxxxxxx>
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 <rich242j@xxxxxxxxx> wrote:
Hey all,
In 12.1.0.2 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.'
