This interests me: "nbemm The usage of one or more system resources has exceeded a warning level. Operations will or could be suspended. Please take action immediately to remedy this situation."
Have a look at EMM logs around the time of the event using:
1) If you can't rememeber which VxUL (Veritas Unified Logging) OID (Originator ID) is related to any given NetBackup component, I like to use this to firstly identify the OID that I need:
> for /f "tokens=1" %a in ('vxlogcfg -l -p 51216') do (vxlogcfg -l -p 51216 -o %a | findstr /i "oidnames")
2) Then you can identify which OIDs are related to EMM, with:
> for /f "tokens=1" %a in ('vxlogcfg -l -p 51216') do (vxlogcfg -l -p 51216 -o %a | findstr /i "oidnames" | findstr /i "emm")
...which should make the 'name' stand out in the list.
3) Now you know which OID(s) you are interested in, but first let's remind ourselves what the default logging levels are for any OID which does not have specific logging levels set:
> vxlogcfg -l -p 51216 -o Default | findstr /i "level"
4) Now let's compare the default logging level, with the logging level of the OID that were interested in, this time were interested in the logging levels of the "nbemm" sub-system/component, so that's OID number 111:
> vxlogcfg -l -p 51216 -o 111 | findstr /i "level"
...yes we could have used the name, instead of the number:
> vxlogcfg -l -p 51216 -o nbemm | findstr /i "level"
...but who ever remembers all of the names and the numbers (but I bet some on here do) - hence the listsing above to identify the OID name or the OID number.
5) Now we know which OID to use, and we've reminded ourselves what the logging levels are, we can begin to query the logs:
> vxlogview -p 51216 -o 111 -b "01/03/2015 19:00:00" -e "19/03/2015 19:05:00"
...but this will most likely generate a huge listing...
...so we need to narrow down the time frame, or narrow down the severity...
...and until you start, you never know whether it's a narrowing of time, or a narrowing of severity which will help you 'spot' the problem(s)...
...so let's use the "-L" switch, with another of these switches to look for increasingly less severe errors, i.e. I first like to look for the most severe events, and then look for decreasingly less severe, e.g. first look for 'emergency' events:
> vxlogview -p 51216 -o 111 -b "01/03/2015 19:00:00" -e "19/03/2015 19:05:00" -L -M
...then critical messages:
> vxlogview -p 51216 -o 111 -b "01/03/2015 19:00:00" -e "19/03/2015 19:05:00" -L -C
...then errors:
> vxlogview -p 51216 -o 111 -b "01/03/2015 19:00:00" -e "19/03/2015 19:05:00" -L -E
...then warnings:
> vxlogview -p 51216 -o 111 -b "01/03/2015 19:00:00" -e "19/03/2015 19:05:00" -L -W
...sadly the vxlogview command doesn't appear to have a way of saying something like 'all warnings and above' e.g. you can't do this '-L -W+' - anyway - narrowing the severity can sometimes help narrow down the time frame, so that you have a smaller set of 'all entries' log to look at - but also narrowing the severity can help you scan a wider period of time... because we don't yet know whether the root cause of your issue occurs at the time of the failure - or is caused by condition that occured at some as yet unknown time before - so sometimes searching for emergencyy, critical, and errors over a wider period of time can you help you spot the pertinent messages.
...lastly you can pipe the output through find or findstr to filter out more and more useless messages, e.g.:
> vxlogview -p 51216 -o 111 -b "01/03/2015 19:00:00" -e "19/03/2015 19:05:00" -L -E | find /i /v "generic error"
HTH.
So, if you can narrow down your logs - then I'm sure others will be greatful at having less to look through.
