Moving studies from one mag to another?

    Hey


    Is there any way of moving studies from one mag to another?


    I have tryed
    dgate --restoremagflags:
    dgate --selectlruforarchival:100000,MAG0
    dgate --movedatatodevice:MAG1,MAG0.Archiving


    commands but nothing happens... dgate.exe just doesnt do nothing. debug doesnt show anything.


    also nightlymovetreshold does not work in latest conquest build.


    it would be super awesome to have command --movestudies:MAG0,MAG1,(date range)



    or is there any way of triggering nightlymove manually so i dont have to wait until 02:00 ?


    Thanx!

    Hi,


    I will test the commands o the latest build.


    This is what nightlymove does:


    dgate -asN


    where N is the #MB to move times 1024


    then


    dgate -amMAG0.Archiving,MAG1


    Assuming MAG1 is nightlymovetarget


    Marcel

    Hi,


    these commands just work for me:


    C:\QUIRT\COMPS\EXE\Dgate>dgate --restoremagflags:
    C:\QUIRT\COMPS\EXE\Dgate>dgate --selectlruforarchival:10000,MAG0


    Did you run dgate in the same folder as were the server is located?


    Marcel

    dgate -as100000
    dgate -amMAG0.Archiving,MAG1


    nothing happens, server log does not show any activity... should it?



    dgate --restoremagflags:
    dgate --selectlruforarchival:10000,MAG0
    dgate --movedatatodevice:MAG1,MAG0.Archiving


    those commands just show in log "command sent using Dgate" or smth and thats it... nothing more happens.



    yes im running dgate from dir where conquest pacs is.



    also im having alot of failures in event log: Faulting application dgate.exe, version 0.0.0.0, faulting module dgate.exe, version 0.0.0.0, fault address 0x00061286.
    windows 2003 R2 sp2



    I think i'll roll back to 14.15 version and see if I still get these issues :)

    Hi,


    I am baffled:


    dgate -am etc work stand-alone: they should run in the dgate you start here.
    dgate -- commands work in the server: and the log should show lots of messages.


    I tested both with 1.4.16rc4b (that is your version, and you use 32 bits?) and they work fine for me. Maybe there is something particular wrong with your configuration? What database do you use? The application faults are in routine newdeletefromdb. This is called when deleting data or when entering data into the database fails. Did you change anything in dicom.sql, or did you change truncatefieldnames in dicom.ini?


    Marcel

    Hey,


    hmm.. yes 1.4.16rc4b and 32bit. Im using MySQL 5.5.8
    I have not changed dicom.sql nor changed truncatedfieldnames in dicom.ini - it's all default.


    This is all that serverstatus shows on these commands:


    dgate --restoremagflags:


    Server command sent using DGATE -- option
    Resetting archive flag on device: MAG0
    Resetting archive flag on device: MAG1



    dgate --selectlruforarchival:100000,MAG0


    Server command sent using DGATE -- option



    dgate --movedatatodevice:MAG1,MAG0.Archiving


    Server command sent using DGATE -- option



    all those commands take long time to execute but what is server doing at that time, I have no information at all... but I do notice that free disk space on MAG0 is not getting bigger and MAG1 aint getting smaller.

    Hi,


    this is what I get for dgate --restoremagflags:


    [CONQUESTSRV1] DGATE (1.4.16rc4b, build Wed Feb 16 21:18:00 2011, bits 32) is running as threaded server
    [CONQUESTSRV1] Database type: native MySQL connection
    [CONQUESTSRV1] Server command sent using DGATE -- option
    [CONQUESTSRV1] Resetting archive flag on device: MAG0
    [CONQUESTSRV1] Resetting archive flag on device: MAG1


    and for dgate --selectlruforarchival:100000,MAG0


    [CONQUESTSRV1] Server command sent using DGATE -- option
    [CONQUESTSRV1] Archival: set archive flag for patient: 00000000
    [CONQUESTSRV1] Archival: set archive flag for patient: 070405SCAN7
    [CONQUESTSRV1] Archival: 19493 KB will be written for patient: 00000000
    [CONQUESTSRV1] Archival: 23505 KB will be written for patient: 070405SCAN7
    [CONQUESTSRV1] Archival: total archive amount: 42998 KB


    If the selected amount will not allow any patient to be processed, you get:


    [CONQUESTSRV1] Server command sent using DGATE -- option
    [CONQUESTSRV1] Archival: nothing to do


    I do use an older version of mysql (5.0.22) on my test machine here. Are there any mysql logs you can look at?


    Marcel

    mysql error log is clean.


    I think I'll test 14.15 version and maybe downgrade to another mysql version in the evening and look how it works out since I have no idea how to debug or trace the problem at the moment.

    EDIT: I did notice now that my mysql innodb buffer pool was too small... maybe that was the whole reason, I upped it and testing again as we speak.
    Maybe I was just trying to move too much at once and sql base got overhelmed by queries.


    first


    [TDKPACS] Connected by address: 0100007f
    [TDKPACS] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
    [TDKPACS] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
    [TDKPACS] 0000,0100 2 US CommandField 48
    [TDKPACS] 0000,0110 2 US MessageID 1
    [TDKPACS] 0000,0800 2 US DataSetType 257
    [TDKPACS] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
    [TDKPACS] 9999,0300 42 LO ConquestConsoleText "Server command sent using DGATE -- option"
    [TDKPACS] 9999,0400 16 LO ConquestConsoleComma "restoremagflags:"
    [TDKPACS] Server command sent using DGATE -- option
    [TDKPACS] Resetting archive flag on device: MAG0
    [TDKPACS] Update Table: DICOMImages
    [TDKPACS] Updates : DeviceName = 'MAG0'
    [TDKPACS] Where : DICOMImages.DeviceName LIKE 'MAG0.%'
    [TDKPACS] Resetting archive flag on device: MAG1
    [TDKPACS] Update Table: DICOMImages
    [TDKPACS] Updates : DeviceName = 'MAG1'
    [TDKPACS] Where : DICOMImages.DeviceName LIKE 'MAG1.%'


    second


    [TDKPACS] Connected by address: 0100007f
    [TDKPACS] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
    [TDKPACS] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
    [TDKPACS] 0000,0100 2 US CommandField 48
    [TDKPACS] 0000,0110 2 US MessageID 1
    [TDKPACS] 0000,0800 2 US DataSetType 257
    [TDKPACS] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
    [TDKPACS] 9999,0300 42 LO ConquestConsoleText "Server command sent using DGATE -- option"
    [TDKPACS] 9999,0400 32 LO ConquestConsoleComma "selectlruforarchival:100000,MAG0"
    [TDKPACS] Server command sent using DGATE -- option
    [TDKPACS] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies, DICOMPatients
    [TDKPACS] Columns : DICOMPatients.PatientID, DICOMPatients.AccessTime
    [TDKPACS] Where : DICOMImages.DeviceName = 'MAG0.Archiving' and DICOMStudies.PatientID = DICOMPatients.PatientID and DICOMImages.SeriesInst = DICOMSeries.SeriesInst and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta
    [TDKPACS] Order : DICOMPatients.AccessTime


    third


    [TDKPACS] Connected by address: 0100007f
    [TDKPACS] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'
    [TDKPACS] 0000,0002 18 UI AffectedSOPClassUID "1.2.840.10008.1.1"
    [TDKPACS] 0000,0100 2 US CommandField 48
    [TDKPACS] 0000,0110 2 US MessageID 1
    [TDKPACS] 0000,0800 2 US DataSetType 257
    [TDKPACS] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2"
    [TDKPACS] 9999,0300 42 LO ConquestConsoleText "Server command sent using DGATE -- option"
    [TDKPACS] 9999,0400 36 LO ConquestConsoleComma "movedatatodevice:MAG1,MAG0.Archiving"
    [TDKPACS] Server command sent using DGATE -- option
    [TDKPACS] Query Distinct Tables: DICOMImages, DICOMSeries, DICOMStudies, DICOMPatients
    [TDKPACS] Columns : DICOMPatients.PatientID, DICOMPatients.AccessTime
    [TDKPACS] Where : DICOMImages.DeviceName = 'MAG0.Archiving' and DICOMStudies.PatientID = DICOMPatients.PatientID and DICOMImages.SeriesInst = DICOMSeries.SeriesInst and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta
    [TDKPACS] Order : DICOMPatients.AccessTime

    Hi,


    these are the correct opening queries (1 reset flags; 2 test if any with flags are there: forbidden; 3) select all with flag). Maybe they take longer than 5 minutes? Then the sending dgate times out. The command just continues. You should at least hget "nothing to do" after it completes.


    Marcel

    Hmm yes but I dont :\


    I'm trying 14.15 version atm and see if it works.


    EDIT: yes.. same happens with 1.4.15



    problably its new mysql version thats causing this problem :(


    I will try to going back to older mysql and newer conquest version and let you know how it goes.


    the whole reason why I upgraded mysql was because database crashed and was not recoverable... so I thought that I might aswell upgrade mysql in process.

    about 6.2+ GB
    5+ mln images
    26k + studies


    if thats the case then I understand.. dgate just timeouts before stuff gets done?



    but is there any way of having somekinde of --movestudies:mag0,mag1(date range) in future?


    at the moment im just manually moving oldest folders from one mag to another and then regenning single directoryes. :)

    Making space at night by moving LRU patients to: MAG1
    Amount of MB to move: 27218
    [TDKPACS] ---------- Start archival operation -----------
    failed selecting patients for nightly moving
    [TDKPACS] ---------- Start archival operation -----------
    failed nightly moving


    hmmm...

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login