Database shut down and file systems are still busy

Question

We have been copying our production DB over to a reporting DB for the last 3 years. The process we use on the reporting database is: shutdown the DB ABORT, restart it, then shutdown immediate. Then we umount the file systems and copy the production over using a Flex Clone on the NETAPP, remount the file systems and start the database back up. We used to shut down the listener which does not share the oracle binaries on the unix system but lately have left the listener up because other DB's use it. Every so often after shutting down the report database in prep for the copy, the file system that contains the binaries is busy and we can't unmount the ORACLE binaries.
So my question is how does the listener know if the database is up or down? Is it reading something on the volumes we're trying to unmount to see if the database is up? We have users that schedule jobs in odd hours and was wondering if them hitting the listener and even though the database is down it's making the file systems busy?
Any help is appreciated.

Answer 1

Mi**** wrote:
So my question is how does the listener know if the database is up or down? If/when the DB responds, then the listener knows it is up;
otherwise listener reports error to client
Is it reading something on the volumes we're trying to unmount to see if the database is up? We have users that schedule jobs in odd hours and was wondering if them hitting the listener and even though the database is down it's making the file systems busy?
Listener is NEVER involved with any ongoing packet exchange between client & the DB.
Listener takes original connection request & if the DB is up passes the request to the DB.
After this initial handoff, the listener has NO more involvement with packet exchange between DB & client