Crontab Solaris: RMAN

Hi
Could you please explain if the following Crontab hour range (07-23) is right for our expectations?  
I means how many times would the script be processed? It is expected only one time.
At what time would it be started It is expected at 7:00.
Regards

See the crontab listing:

/lanza_backup_SISNET.err
30 07-23 * * * /opt/oracle/scripts/rman/dispara_backup_archives.sh  1>/dev/null 2>/dev/null

Hi again,
This question is something I have found in a hot environment. I think the person who did the script or assigned this entry in the crontab wanted the script to run in a window from 7:30 to 23, or so.
I am afraid this is not  WHAT it is happening but I am not sure and I cannot try easily test it.
As mather on fact the Oracle Data Base was shut down because of that and I guess the RMAN script is being executed each hour.
Can anyone give me some advise and comments?
Enrique Gomez EstebanConsultantAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David FavorLinux/LXD/WordPress/Hosting SavantCommented:
The CRON entry you provided will run once every hour, at the 30 minute mark, for the hours 7-23.

Your log is being piped to /dev/null so any errors... will just cause a failure... you'll never know a failure occurred.

I'd suggest your use a real log file + just rotate your logs every day.
0
arnoldCommented:
look in /var/log/cron /var/log/ocron to see what happens when this job is called to confirm the running of the job at the half hour from 7-23 as David pointed.

Please clarify what you are asking.
RMAN is an oracle backup/transaction mechanism.
what does the script do when called?
Do not believe the oracle DB is shutdown when rman runs.
Check the logs of oracle to see when and what led to its shutdown...
I found that it is better to understand the environment in which one operates before jumping to conclusion of a single item that does not seem familiar based on one's experience.
i.e. for uniformitty the cron above would commonly be run on an hourly basis whether the traffic/amount of transactions between midnight and 7 am are few one can not anticipate another DBA utilizing off-peak hours to run a process that might generate issues .....
0
Enrique Gomez EstebanConsultantAuthor Commented:
Well yes. I think you are right.
The Oracle DB is shut sown and I am suspicious that the above script that launch RMAN in the crontab could be the reason, but I am not sure.
Find  some logs  (alert log Oracle) . First the Oracle instance shutdown an later some previous log lines about generating many redo before shuting down.  Hope this could help.

***********************************************************************
328484  
328485  Fatal NI connect error 12537, connecting to:
328486   (LOCAL=NO)
328487  
328488    VERSION INFORMATION:
328489          TNS for Solaris: Version 11.2.0.4.0 - Production
328490          Oracle Bequeath NT Protocol Adapter for Solaris: Version 11.2.0.4.0 - Production
328491          TCP/IP NT Protocol Adapter for Solaris: Version 11.2.0.4.0 - Production
328492    Time: 21-NOV-2017 20:26:30
328493    Tracing not turned on.
328494    Tns error struct:
328495      ns main err code: 12537
328496    
328497  TNS-12537: TNS:connection closed
328498      ns secondary err code: 12560
328499      nt main err code: 0
328500      nt secondary err code: 0
328501  opiodr aborting process unknown ospid (5842) as a result of ORA-609
328502      nt OS err code: 0
328503  Errors in file /opt/oracle/diag/rdbms/sisnet/SISNET/trace/SISNET_lgwr_25239.trc  (incident=99785):
328504  ORA-00494: enqueue [CF] held for too long (more than 900 seconds) by 'inst 1, osid 25345'
328505  Tue Nov 21 20:26:30 2017
328506  
328507  
328508  ***********************************************************************
328509  
328510  Fatal NI connect error 12537, connecting to:
328511   (LOCAL=NO)


  Time: 21-NOV-2017 20:26:30
328678    Tracing not turned on.
328679    Tns error struct:
328680      ns main err code: 12537
328681    
328682  TNS-12537: TNS:connection closed
328683      ns secondary err code: 12560
328684      nt main err code: 0
328685      nt secondary err code: 0
328686      nt OS err code: 0
328687  opiodr aborting process unknown ospid (5850) as a result of ORA-609
328688  opiodr aborting process unknown ospid (5856) as a result of ORA-609
328689  opiodr aborting process unknown ospid (5854) as a result of ORA-609
328690  opiodr aborting process unknown ospid (5860) as a result of ORA-609
328691  opiodr aborting process unknown ospid (5858) as a result of ORA-609
328692  Tue Nov 21 20:26:30 2017
328693  


    nt secondary err code: 0
328918      nt OS err code: 0
328919  opiodr aborting process unknown ospid (5876) as a result of ORA-609
328920  opiodr aborting process unknown ospid (5880) as a result of ORA-609
328921  opiodr aborting process unknown ospid (5878) as a result of ORA-609
328922  Killing enqueue blocker (pid=25345) on resource CF-00000000-00000000 by (pid=25239)
328923   by killing session 938.1
328924  Killing enqueue blocker (pid=25345) on resource CF-00000000-00000000 by (pid=25239)
328925   by terminating the process
328926  LGWR (ospid: 25239): terminating the instance due to error 2103
328927  Tue Nov 21 20:26:32 2017
328928  ORA-1092 : opitsk aborting process
328929  Tue Nov 21 20:26:32 2017
328930  ORA-1092 : opitsk aborting process
328931  Tue Nov 21 20:26:32 2017
328932  System state dump requested by (instance=1, osid=25239 (LGWR)), summary=[abnormal instance termination].
328933  System State dumped to trace file /opt/oracle/diag/rdbms/sisnet/SISNET/trace/SISNET_diag_24855_20171121202632.trc
328934  Instance terminated by LGWR, pid = 25239
328935  Tue Nov 21 21:07:10 2017
328936  Starting ORACLE instance (normal)
328937  LICENSE_MAX_SESSION = 0
328938  LICENSE_SESSIONS_WARNING = 0
328939  Initial number of CPU is 16
328940  Number of processor cores in the system is 8
328941  Number of processor sockets in the system is 2
328942  CELL communication is configured to use 0 interface(s):
328943  CELL IP affinity details:
328944      NUMA status: non-NUMA system
328945      cellaffinity.ora status: N/A
328946  CELL communication will use 1 IP group(s):






   Current log# 2 seq# 90310 mem# 1: /u02/oradata/SISNET/rdofilesb/redo02b.log
328122  Tue Nov 21 19:59:55 2017
328123  Archived Log entry 89542 added for thread 1 sequence 90309 ID 0x1407aec7 dest 1:
328124  Thread 1 advanced to log sequence 90311 (LGWR switch)
328125    Current log# 1 seq# 90311 mem# 0: /u02/oradata/SISNET/rdofilesa/redo01.log
328126    Current log# 1 seq# 90311 mem# 1: /u02/oradata/SISNET/rdofilesb/redo01b.log
328127  Tue Nov 21 20:00:04 2017
328128  Archived Log entry 89543 added for thread 1 sequence 90310 ID 0x1407aec7 dest 1:
328129  Tue Nov 21 20:00:23 2017
328130  Thread 1 advanced to log sequence 90312 (LGWR switch)
328131    Current log# 4 seq# 90312 mem# 0: /u02/oradata/SISNET/rdofilesa/redo04.log
328132    Current log# 4 seq# 90312 mem# 1: /u02/oradata/SISNET/rdofilesb/redo04b.log
328133  Tue Nov 21 20:00:28 2017
328134  Archived Log entry 89544 added for thread 1 sequence 90311 ID 0x1407aec7 dest 1:
328135  Tue Nov 21 20:00:35 2017
328136  Thread 1 cannot allocate new log, sequence 90313
328137  Private strand flush not complete
328138    Current log# 4 seq# 90312 mem# 0: /u02/oradata/SISNET/rdofilesa/redo04.log
328139    Current log# 4 seq# 90312 mem# 1: /u02/oradata/SISNET/rdofilesb/redo04b.log
328140  Thread 1 advanced to log sequence 90313 (LGWR switch)
328141    Current log# 5 seq# 90313 mem# 0: /u02/oradata/SISNET/rdofilesa/redo05.log
328142    Current log# 5 seq# 90313 mem# 1: /u02/oradata/SISNET/rdofilesb/redo05b.log
328143  Tue Nov 21 20:00:42 2017
328144  Archived Log entry 89545 added for thread 1 sequence 90312 ID 0x1407aec7 dest 1:
328145  Tue Nov 21 20:01:11 2017
328146  Thread 1 cannot allocate new log, sequence 90314
328147  Checkpoint not complete
328148    Current log# 5 seq# 90313 mem# 0: /u02/oradata/SISNET/rdofilesa/redo05.log
328149    Current log# 5 seq# 90313 mem# 1: /u02/oradata/SISNET/rdofilesb/redo05b.log
328150  Tue Nov 21 20:09:22 2017
328151  
328152  
328153  ***********************************************************************
328154  Tue Nov 21 20:16:26 2017
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

arnoldCommented:
Look what the script does, ask on oracle DBA to check db health. Table space.
I do not believe Rman needs  db/listener tob shutdown.
Not sufficiently familiar to understand the logs or whether these are the events preceding the db crash.
0
slightwv (䄆 Netminder) Commented:
I agree that you need to have your DBA check everything.

From the name of the script, it seems to backing up your archived redo logs.  Depending on your system, it might be perfectly acceptable to do this throughout the day.  We cannot say since we know nothing about your system.

We also cannot say if that script has anything to do with the instance crash.

I would contact Oracle Support on this one.  They have the tools to help you dig into the actual cause.

First I would look at this document on Oracle Support:
Troubleshooting ORA-494 Errors (Doc ID 1915481.1)
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Gerwin Jansen, EE MVETopic Advisor Commented:
>> I means how many times would the script be processed? It is expected only one time.
If you're new to cron and don't want to go through the manual, try this to see how many times it's running your job:

30 07-23 * * * echo $(date) >> /var/tmp/cronlog.txt

The above will just echo date/time to that cronlog.txt file - after a day you should have 17 lines in it similar to this:

Sat Nov 25 21:30:00 CET 2017
0
Enrique Gomez EstebanConsultantAuthor Commented:
Thanks a lot for your help & comments. After re-scheduling  some jobs and exports the errors have dissapeaed so far.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.