HOWTO - Easy troubleshooting steps for issue on numerous sessions in queue state

  • KM02757499
  • 23-Mar-2017
  • 23-Mar-2017

This document has not been formally reviewed for accuracy and is provided "as is" for your convenience.


(DP) Support Tip: Easy troubleshooting steps for issue on numerous sessions in queue state


DP GUI Monitor or omnistat shows a very high number of sessions waiting in queue.

Example :

# omnistat
SessionID Type Status User
2017/03/14-12 Restore In Progress
2017/03/14-13 Backup In Progress
2017/03/14-14 Backup In Progress
2017/03/14-15 Restore In Progress
2017/03/14-16 Backup In Progress
2017/03/14-17 Backup In Progress
2017/03/14-18 Backup Queuing
2017/03/14-19 Backup Queuing
2017/03/14-20 Backup Queuing
2017/03/14-21 Backup Queuing
2017/03/14-22 Backup Queuing
2017/03/14-23 Backup Queuing
2017/03/14-24 Backup Queuing
2017/03/14-25 Backup Queuing
2017/03/14-26 Backup Queuing
2017/03/14-27 Backup Queuing
2017/03/14-28 Backup Queuing
2017/03/14-29 Backup Queuing
2017/03/14-30 Backup Queuing
2017/03/14-31 Backup Queuing
2017/03/14-32 Backup Queuing
2017/03/14-33 Backup Queuing

This is not ideal - when the number of sessions in queuing/wait state is equal or more than the number of active/running sessions.

Review your configuration and determine if they are all within order.

1. Review your backup schedules

Generate Schedule report :

omnirpt -report dl_sched


Shows information about all selected backup, object copy, object consolidation, and object verification specifications and their next scheduled time up to one year in advance (type, session type, session specification name, group, next execution, and backup operation time).

By default, the report is generated for all session specifications. Use the report filtering options to generate a report only for a specific backup, object copy, object consolidation, or object verification specification.

Verify the output backup schedule report to be matching to what you have configured and what is your Enterprise Backup Solutions requirements.

You have to determine how many backups run at the same time and then decide if this is ideal as per your current environment.

If you know the number of devices you have OR other sessions running, such that devices are still in-use, then you can determine when should the next backup will need to run. Better to delay backup start rather than having it wait in queue.

Key Point - there is no need to run a backup if there is no available device (and license) as making this session wait puts additional load to your Cell Manager, in terms of system resources.


2. Ensure that the global timeout parameter is default or within a valid range

WINDOWS : C:\ProgramData\OmniBack\Config\Server\Options\global
UNIX : /etc/opt/omni/server/options/global

# SmWaitForDevice=WaitForInMinutes

# default: 90 minutes
# This timeout is used by the Backup Session Manager. The
# Backup Session Manager first tries to get a lock for all
# devices that will be used for backup. If a lock can not be
# obtained for the desired devices, the BSM will wait for the
# specified time-out. If it can not get a lock for the devices,
# the backup session will fail. If dynamic is used then the
# Backup Session Manager tries to get a lock for the minimum
# number of devices used for backup. In general,
# SmWaitForDevice is used as a time-out for different kinds of
# queuing (queuing for lock, license etc.).

If a device is being used by a session and a new backup session is started which uses the same device, it will wait within the time specified in parameter SmWaitForDevice.

The SmWaitFordevice parameter is honored - meaning the session will abort if the device is not available, after it waits for the configured amount of time specified.

The reason the session queue is getting longer with so many sessions in wait state is because this parameter have been increased for a very high value - for many hours. The default value should be more than enough and unless there is a valid reason, better to keep to default.


If the above two items are good, then you will need to determine if any backup session is running way beyond (abnormal) of it's start and end time, specific to the backed-up data. You will need to check the previous session for this same backup for reference.