cancel
Showing results for 
Search instead for 
Did you mean: 

System disk group offline message when scanning. What is being written to the System disk group that is causing this error and how do I fix it?

James_Perry
Elite Collaborator
Elite Collaborator

Multiple users are getting the Platter Management Error - Problem locating ID file for Disk Group: The uncommitted copy of the Disk Group is currently off line. Copy 1 is the uncommitted copy for System Docs.

This is not a new problem in our system according to my research but it is a more frequent issue for many users lately but it has been since 2009-12-15.

·        1032 times already in 2016 (4 months)

·        88 times in 2015

·        214 times in 2014

·        182 times in 2013

·        172 times in 2012

·        50 times in 2011

·        50 times in 2010

·        8 times in 2009 (4 days)

** This does not happen for anyone in the MANAGER group when we test a scan as far as I can see.

Is this due to multiple people scanning and ‘locking’ the disk group? What would be writing to the System Docs disk group when scanning?

Here is the section of the Verbose Log where we are seeing the error.

>> 04/28/2016 09:09:16:920  [Thread:2272]

Lock, ReturnValue = 0, Keytype = 64(Disk Group ), Keynum = 103, UserNum = 1194,

RegisterNum = 2405

>> 04/28/2016 09:09:16:920  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Select hsi.diskgroup.diskgroupnum, hsi.diskgroup.diskgroupname,

hsi.diskgroup.currentdirectory, hsi.diskgroup.diskgrouptype,

hsi.diskgroup.diskthreshold, hsi.diskgroup.filesindirectory,

hsi.diskgroup.filesperdirectory, hsi.diskgroup.lifespan,

hsi.diskgroup.numberofbackups, hsi.diskgroup.ucautopromotespace,

hsi.diskgroup.autopromotespace, hsi.diskgroup.lastlogicalplatter,

hsi.diskgroup.cachepath, hsi.diskgroup.lpnumsyscache, hsi.diskgroup.cachelpnum,

hsi.diskgroup.lpcachethreshold, hsi.diskgroup.formatnum,

hsi.diskgroup.committedlp, hsi.diskgroup.numberofexports,

hsi.diskgroup.prepathed, hsi.diskgroup.exportmgrnum, hsi.diskgroup.adminusernum

, hsi.diskgroup.retentionyears, hsi.diskgroup.flags, hsi.diskgroup.description

From hsi.diskgroup

Where hsi.diskgroup.diskgroupnum = 103

>> 04/28/2016 09:09:16:920  [Thread:2272]

>> 04/28/2016 09:09:16:920  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Select hsi.physicalplatter.diskgroupnum, hsi.physicalplatter.logicalplatternum,

hsi.physicalplatter.physicalplatternum, hsi.physicalplatter.plattertype,

hsi.physicalplatter.diskidalias, hsi.physicalplatter.diskidfilename,

hsi.physicalplatter.diskidflag, hsi.physicalplatter.diskidsize,

hsi.physicalplatter.lastuseddrive, hsi.physicalplatter.spacefree,

hsi.physicalplatter.spaceused, hsi.physicalplatter.disksearchorder,

hsi.physicalplatter.blocksize, hsi.physicalplatter.maxcacheplatters,

hsi.physicalplatter.platterdeleted, hsi.physicalplatter.onbackupqueue,

hsi.physicalplatter.maxlogicalplatter, hsi.physicalplatter.minlogicalplatter,

hsi.physicalplatter.dbnum, hsi.physicalplatter.plattercreated,

hsi.physicalplatter.ondeletequeue, hsi.physicalplatter.plattertype2

From hsi.physicalplatter

Where hsi.physicalplatter.diskgroupnum = 103 and

hsi.physicalplatter.logicalplatternum = 528

order by hsi.physicalplatter.disksearchorder

>> 04/28/2016 09:09:16:920  [Thread:2272]

>> 04/28/2016 09:09:16:935  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Update hsi.maxnumkeys set maxnum = maxnum + 1 where keykeytype = 13

>> 04/28/2016 09:09:16:935  [Thread:2272]

>> 04/28/2016 09:09:16:935  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Select hsi.maxnumkeys.keykeytype, hsi.maxnumkeys.keytypename,

hsi.maxnumkeys.maxnum, hsi.maxnumkeys.slock, hsi.maxnumkeys.usernum

from hsi.maxnumkeys with (NOLOCK)

where keykeytype = 13

>> 04/28/2016 09:09:16:935  [Thread:2272]

>> 04/28/2016 09:09:16:935  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Insert into hsi.pltrmgmtlog ( usernum, registernum, logdate, severityflag,

userresponse, messagetext, actionnum, subactionnum, diskgroupnum,

logicalplatternum, physicalplatternum, tracelvl ) values ( 1194, 2405, {fn

now()}, 0, 0, 'Platter Management Error: Problem locating ID File for Disk

Group:  The uncommitted copy of the Disk Group is currently off line.  Please

contact your system administrator.    System ID:       123456', 1, 2, 103, 528,

1, 0)

>> 04/28/2016 09:09:16:935  [Thread:2272]

>> 04/28/2016 09:09:16:935  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Insert into hsi.pltrmgmtlog ( usernum, registernum, logdate, severityflag,

userresponse, messagetext, actionnum, subactionnum, diskgroupnum,

logicalplatternum, physicalplatternum, tracelvl ) values ( 1194, 2405, {fn

now()}, 0, 0, '  Disk Group Name: System Docs  Disk Group #:    103  Volume #:

      528  Copy #:          1

Error: GetIdFile 2: -6  ', 1, 2, 103, 528, 1, 0)

>> 04/28/2016 09:09:16:935  [Thread:2272]

>> 04/28/2016 09:09:19:657  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Update hsi.diskgroup Set diskgroupnum=103, diskgroupname='System Docs',

currentdirectory=52, diskgrouptype=8, diskthreshold=0, filesindirectory=42,

filesperdirectory=500, lifespan=0, numberofbackups=2, ucautopromotespace=500000

, autopromotespace=0, lastlogicalplatter=528, cachepath='', lpnumsyscache=0,

cachelpnum=0, lpcachethreshold=0, formatnum=0, committedlp=0, numberofexports=0

, prepathed=0, exportmgrnum=0, adminusernum=0, retentionyears=0, flags=0,

description=''  Where hsi.diskgroup.diskgroupnum =  103 And

hsi.diskgroup.lastlogicalplatter =  528

>> 04/28/2016 09:09:19:657  [Thread:2272]

>> 04/28/2016 09:09:19:673  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Update hsi.physicalplatter Set plattertype=393218, diskidalias='',

diskidfilename='', diskidflag=0, diskidsize=0, lastuseddrive

='\\itobdata\SYSDOCS', spacefree=0, spaceused=96439, disksearchorder=0,

blocksize=0, maxcacheplatters=0, platterdeleted=0, onbackupqueue=0,

maxlogicalplatter=0, minlogicalplatter=1, dbnum=0, plattercreated=1,

ondeletequeue=0, plattertype2=0 Where hsi.physicalplatter.diskgroupnum =  103

And hsi.physicalplatter.logicalplatternum =  528 And

hsi.physicalplatter.physicalplatternum =  1

>> 04/28/2016 09:09:19:673  [Thread:2272]

>> 04/28/2016 09:09:19:673  [Thread:2272]

UnLock, ReturnValue = 0, Keytype = 64(Disk Group ), Keynum = 103, UserNum =

1194, RegisterNum = 2405

>> 04/28/2016 09:09:21:233  [Thread:2272]

[DB Connection: 0x5B7E4F8]

SELECT {fn now()}

FROM hsi.licensetable

>> 04/28/2016 09:09:21:233  [Thread:2272]

>> 04/28/2016 09:09:21:233  [Thread:2272]

[DB Connection: 0x5B7E4F8]

Update hsi.archivedqueue Set queuenum=216, queuename='HD Clinics Charts',

batchname='2016-04-28 - VEH24832 - #136429 - ZARA, ROMEO', status=2,

tmpdiskgroupnum=206, tmplogicalplttrnum=64, diskgroupnum=206, logicalplatternum

=64, usernum=1194, datestarted=2016-04-28 09:08:29.0, dateended=2016-04-28

09:09:19.0, numberdocuments=0, archiveflags=0, bitmapnum=0, iconnum=0,

lastusedplatter=0, totalpages=65536, printeddate=1964-01-01 00:00:00.0,

totaldocuments=1, batchflags=0, registernum=2405 Where

hsi.archivedqueue.batchnum =  725306

>> 04/28/2016 09:09:21:233  [Thread:2272]

No one person needs to know everything—they simply need to know who knows it.
2 ACCEPTED ANSWERS

Hi James,

I've done some quick testing to see if I can replicate what you've described above, and so far I haven't been able to find a situation where the scanning logic tries to mount the system diskgroup - unless of course the scan queue in question happens to be assigned to use the system diskgroup (which isn't your setup, I can see that from the verbose entries).  So I don't have an immediate explanation for what you're seeing - at this point I'd suggest opening up a support issue with your support representative so we can do some more in depth troubleshooting against your system so we can determine exactly what step of your process is trying to mount the system diskgroup. 

View answer in original post

Marcus_Christi2
Elite Collaborator
Elite Collaborator

Chiming in...

Image Processing will write a Verification Report.  If the user is kicking that off (rather than a background schedule), that's likely a culprit.

Anything the user does that generates a Verification Report, to my knowledge, writes to System under their credentials.

View answer in original post

4 REPLIES 4

Hi James,

I've done some quick testing to see if I can replicate what you've described above, and so far I haven't been able to find a situation where the scanning logic tries to mount the system diskgroup - unless of course the scan queue in question happens to be assigned to use the system diskgroup (which isn't your setup, I can see that from the verbose entries).  So I don't have an immediate explanation for what you're seeing - at this point I'd suggest opening up a support issue with your support representative so we can do some more in depth troubleshooting against your system so we can determine exactly what step of your process is trying to mount the system diskgroup. 

Steve, thank you for the response. We have had our first level support looking into this and captured many logs trying to determine the issue.

I am hoping that someone might know if any image processing or document creation logging might be triggering the system disk group requests.
No one person needs to know everything—they simply need to know who knows it.

It turns out that we need to add the users to a group with modify rights to our System Docs disk group folder location. The scan queues are not configured to use the System disk group but something is requesting to write data there.
No one person needs to know everything—they simply need to know who knows it.

Marcus_Christi2
Elite Collaborator
Elite Collaborator

Chiming in...

Image Processing will write a Verification Report.  If the user is kicking that off (rather than a background schedule), that's likely a culprit.

Anything the user does that generates a Verification Report, to my knowledge, writes to System under their credentials.