You need to provide more detail information ... from this I see shutdown initiated by user.
What platform are you on? Do you have a cron doing a bounce for backups? Does it happen at the same time? Are you on a VM?
Occasionally, it automatically shuts itself down
Shutting down instance (immediate)
The two statements above are in direct opposition to itself. The database will not automatically shut itself down and the second line shows a SHUTDOWN IMMEDIATE was explicitly requested. Now maybe you didn't do the requesting, but someone or better yet...something made the request. Check for scheduled batch jobs that are performing a cold backup...or one that the previous DBA implemented to perform a regular restart "just to clear things up".
Like other members have mentioned, without an explicit attempt, it's not possible. So check for any scheduled jobs, review the auditing logs and ask around if someone is having itchy fingers.
Just two cents, From the timings of shutdown and startup, as others said, look at various logs and cron jobs
There's different ways to find out, one is to start changing passwords. Of course, using the pre-designed method.
It could be an external system, reaching out to your server.
Could be a lot, really. But just check Crontab
Is it running in noarchive,log mode? May be it gets shut down for cold backup?
Is there a time gap between shutdown and startup?
What's about the server where the database is running? Does it stay up or it also gets restarted? On UNIX user "uptime" to determine when a server was restarted.
Thank you very much for all of the replies. My sincere apologies for not fully complying with all forum rules and etiquettes.
This is a QE automatic environment where the problem is seen occasionally (not always).
It cannot be reproduced in development or other manually driven QE environment.
Here is the information on the automatic process and its environment.
* It accepts a job request with all necessary parameters from a user
* it arbitrarily allocates a host machine - a Linux (OLE5/6) image, from a pool of hosts
* It installs the DB (oracle 22.214.171.124.0) on the that host
* It installs the applications/products on the same host
* It runs all kinds of test scripts that include some selenium tests for UI implemented using Oracle ADF
* It occasionally fails only on selenium tests
* After completion of the job, it creates a job report on partially or fully successful tests.
* The host image is available for a few hours after the job completion notification
* Users have access to DB log files and application log files for a few hours.
* The host image is then retuned to the pool of hosts and thereafter no further access to the host is possible.
Well, in the absence of other errors, the likelihood is either there is something wrong with the script, or somehow it is getting run twice without actually creating a new VM (I'm guessing however it is created assumes it is not in use), or you have some backup routine for the VM that shuts down the db in conflict with the test, or something else is wrong.
I have seen situations where VMs run out of resources and restart, leaving old ones hanging, but that depends on the VM.