Bulk study move between storage devices

    Hello,


    I have a problem and I'm not sure what is the best way to aproach it.
    What I have now is all studies are on 1 device: MAG0
    What I'd like to do is to create 2nd device: MAG1 (that part is easy) and move certain studies there then remove them from MAG0.


    Moving all that in one go would probably kill my network and/or server so I'd like to split the process.
    Someone told me that there is a way to FLAG an image/study in the database - something like adding ".Archival" to device name? he wasn't sure and I can't find it anywhere in the manual.
    That would be easy enough and would also allow me to split the process.


    So the question is: is this true? Can I just flag them in postgress? If so then I assume that after that I'd have to invoke some command to force archivization process?


    Bonus question: I guess it is possible to automate this process after that initial move. Any hints?

    Try:


    dgate -v -as1000000,0
    dgate -v --amMAG0.Archiving,MAG1


    this selects 1 GB data and moves it to MAG1. This can be automated using a windows scheduled task. In the windows GUI there is a setting on the settings page to do this each night.


    Marcel

    Thank you for help.


    As I was trying this I ran into a small problem, maybe even potential bug.


    Command that you gave me produces this querry:


    As you can see the name of the table is correct in the first instance because of my dicom.ini entry:

    Quote


    # Names of the database tables
    PatientTableName = DICOMPatients
    StudyTableName = DICOMStudies_view


    However the second and third are not. No idea where it came from.. (hardcoded?)


    [edit]
    Also, as a side note or just a warning to anyone who would want to do that - check if you have an index on 'devicename' in dicomimages table or you will kill your database with this query :) Otherwise it will do a sequential scan of whole table.. 35.000.000 rows (13Gb) in my case sooo. yea.. that's bad :)
    [/edit]

    Hi,


    some of the field names are indeed hardcoded, so changing the field names causes this bug. I will add it to the buglist. However, I would suggest all users NOT to change field names, this option is not tested.


    Furthermore, because this action runs nightly the linear scan is only a limited problem. We successfully used this option for years in a 10 million images database.


    Marcel

    I see.. well, if it is a known problem then it's OK.


    About name changes - I didn't have a choice. Basically I was forced to create a view of this table because of some bad design of 3rd party software which was killing PG with poorly optimized query of this table.


    So the bottom line is that "dgate -v --amMAG0.Archiving,MAG1" will just NOT work with changed table name, am I right? Any workaround maybe?

Participate now!

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

Register Yourself Login