Oracle Database Discussions

Hello ,

I also evaluate the performance of oracle 11g DICOM , and I use an open source tools dcm4che. The only adaptation is I change the storing method from the filesystem to the DB . I test the performanace both the BFILE and BLOB , the performance diversity is not so big .

If you like , we can share the test strategy . Also I will still adapt my test case and find the best performance method .

Thank you .

Hello!!!

It's amazing, we are exactly trying to do the same!!

We are using dcm4che v2.11.0 and trying to modify it in order to store DICOM images into DB. The procedure we are following is as follows:

In dcm4jboss_sar project --> StoreScp Class --> doCStore Method

In that method we have the InputSream which we think we have the whole Image and we are trying to store it into DB using a BLOB data type. These are the modifications we are doing:

protected void doCStore(ActiveAssociation activeAssoc, Dimse rq,
Command rspCmd) throws IOException, DcmServiceException {
System.out.println("pasando por doCStore de StoreScp.java");
Command rqCmd = rq.getCommand();
InputStream in = rq.getDataAsStream();
storeImage(in, rq.getDataset().getString(Tags.PatientID));

Association assoc = activeAssoc.getAssociation();
.....
.....
}

private void storeImage(InputStream in, String patientId) {
try {
Connection connection = DriverManager.getConnection
("jdbc:oracle:thin:@10.60.0.44:1521:CARDIO", "cardio_11", "cardio_11");
PreparedStatement pst=null;
ResultSet rs=null;
//obtenemos el proximo valor de la secuencia
int id=1;
String SQL_UPLOAD_SECUENCIA =
" select IMAGE_TABLE_PK_SEQ.nextval as secuencia from dual";

pst = connection.prepareStatement(SQL_UPLOAD_SECUENCIA);
rs = pst.executeQuery();

if (rs.next()) {
id = rs.getInt("secuencia");
}

String SQL_UPLOAD_IMAGE =
" INSERT INTO IMAGE_TABLE(" +
" ID, " +
" IMAGE) " +
" VALUES(" +
id + "," +
" empty_blob())";
pst = connection.prepareStatement(SQL_UPLOAD_IMAGE);
pst.executeUpdate();
pst.close();
pst =connection.prepareStatement("SELECT IMAGE" +
" FROM IMAGE_TABLE" +
" WHERE ID = " + id +
" FOR UPDATE");
rs = pst.executeQuery();

rs.next();
OutputStream outstream = null;
BLOB blob = ((OracleResultSet) rs).getBLOB(1);
outstream = blob.getBinaryOutputStream();

int size = blob.getBufferSize();
byte[] buffer = new byte[size];
int length = -1;
while ((length = in.read(buffer)) != -1) {
outstream.write(buffer, 0, length);
}
outstream.close();
pst.close();
}catch (Exception e) {
e.printStackTrace();
}
}

we are having problems with data model referential integrity since we are using a table to store the image composed by an id,image,patien_id foreing key to patien table.

please, could you tell us if we are going in the good way and if you managed to make it work? could you give us some advises about the modifications you made on the data model dcm4che creates on DB?

I really thank your help and I leave you my email in the case you prefer, if you want I can send you my testting classes to your email:

lucasg@sescam.jccm.es

Hi,

To avoid the complicated usage of dcm4chee ,I am using currectly dcm4che2 DICOM toolkit and utilities to only do some simple test by modifying the DcmRcv.java .

DcmRcv.java ->public void cstore-->onCStoreRQ

But it seems that we use the similar method to store the Dicom content into the DB . My method is

1 ,store them first into a Blob by the datastream from the Network
2.,using a Dicom constructor to store the Blob into a Dicom object table by a PL/SQL Procedure.

Java Code
........
stmt.executeUpdate("insert into blob_tbl(id,my_blob) values('" + in + "',empty_blob())");

ResultSet rs = stmt.executeQuery("select my_blob from blob_tbl where id='" + in + "' for update" );

if(rs.next())
{
Blob blob = rs.getBlob(1);
OutputStream out = ((oracle.sql.BLOB)blob).getBinaryOutputStream();

byte[] b = new byte[((oracle.sql.BLOB)blob).getBufferSize()];
InputStream fin = inStream;
int len = 0;
while( (len = fin.read(b)) != -1)
out.write(b,0,len);
fin.close();
out.close();
conn.commit();
}

.......

SQL Procedure :

-- Set Data Model Repository
execute ordsys.ord_dicom.setDataModel();


create or replace procedure Dicom_BLOB_Construct(dest_id number) is

begin
insert into OBJ_tbl (id, dicom)
( select s.id, ORDDicom(s.my_blob) from blob_tbl s
where s.id=dest_id);
commit;
end;

/
show errors;


How do you handle the DICOM object when you load the dicom into Blob ?

Hello,

i never tried to store DICOM Images directly in the PACS and i guess it will put too much stress on the oracle db.

It may be fine for very small facilities, but you have to keep in mind that nowadays its not unlikely to have CT scans that consist of 800 or more images, each about 512K and those images are produced (and expected to be stored) within a very short time window. And most institutions are doing quite a couple of those exams per day.

Beside those "lot off small images"- examinations you will have the other extreme as well - mammography exams with typically 4 images per exam but each image a minimum of about 32MB.

So again - i don't think its a good idea to store images directly in the pacs db. of course you could avoid inconsistencies between the db and the file systems but usually you can keep track of them with tools provided by your pacs vendor.

kind regards

I realize this is quite an old entry, but it just came to my attention. Please note that the best place to post questions about Oracle Database DICOM support is the Oracle Multimedia forum is at 3080 which is typically where DICOM/medical imaging topics are discussed. Oracle Multimedia is a feature of the database and in Oracle Database 11g includes comprehensive support for managing DICOM images in the database. The conclusion arrived at in the above posts about storing images in the database is incorrect. The performance figures appear to be way off perhaps because the database was not tuned appropriately.

To achieve the best possible performance, one must make the proper choice regarding data storage, the selection of application APIs and database tuning. You can find benchmark data on extensive tests with a 2 TB DICOM dataset encompassing various image and study sizes in 6 different modalities at http://www.oracle.com/technology/products/intermedia/pdf/ora_dicom_bench_2008.pdf . The DICOM performance benchmark essentially shows that software (Oracle Database 11g) does not impose any bounds on performance. Speeds are hardware bound, and the performance benchmark shows that speeds were as fast as the underlying hardware allowed. Additionally the database scales better with multiple processors and larger images. Images as large as 128 TB each can be stored and retrieved and the database size can be in the exabytes range.

Regarding your test results:
At first glance in the code snippet posted here it appears that SecureFiles were not used (the old basic lobs were used) and stream interfaces were used in the Java application. Much better performance can be realized with the java.sql.Blob.getBytes() and putBytes() interfaces. This is described in the DICOM performance benchmark paper, along with several other things to keep in mind for best performance. If you still encounter performance issues please contact Oracle Support who can help you with tuning or write to me at melliyal <dot> annamalai <at> oracle <dot> com .

Additional information about Oracle Multimedia DICOM support can be found on OTN at http://www.oracle.com/technology/products/intermedia/index.html. The page also includes quotes from satisfied customers who have stored DICOM images in the database.

Melli Annamalai
Product Manager, Oracle Multimedia

Additional information about Oracle Multimedia DICOM support can be found on OTN at http://www.oracle.com/technology/products/intermedia/index.html. The page also includes quotes from satisfied customers who have stored DICOM images in the database.

With performance equaling or exceeding that of file systems there are several advantages to storing the DICOM images in the database along with the metadata. Here are just a few: (1) there would be no inconsistencies between the images and metadata (as has been pointed out as an issue with file systems in this post), (2) images can be securely and privately stored, with all the database security features being applied to images, (3) there is a uniform interface for managing images, metadata, and other patient data, with no need for different tools from different vendors, (3) as has been correctly observed in this post images are growing rapidly in size and number, and a database has several features for scalability such as support for grid architectures, automatic storage management, partitioning, information lifecycle management, and so on, (4) disaster recovery, backup, and availability are intrinsic features of the database.

The DICOM support in the database also includes DICOM specific functionality for all forms of DICOM content – images, video, structured reports. All metadata, DICOM standard attributes and device vendor-specific attributes, can be extracted. The extracted metadata is stored in an XML representation enabling complex and detailed searches. DICOM content can be validated to ensure that the metadata they contain conforms to specifications. Metadata can be anonymized for the DICOM content to be used in research. DICOM images can be converted into JPEG or other supported formats, cut to highlight specific regions, converted into thumbnails for inclusion in reports, etc. In summary Oracle Multimedia DICOM functionality includes a comprehensive set of features that enables the database to be used as infrastructure for PACS, medical image archives, and other systems.

Please write to me if you would like to know more.

Melli
melliyal <dot> annamalai <at> oracle <dot> com

Information on OracleSecureFiles, that the DICOM performance benchmark used for storage, is at http://www.oracle.com/technology/products/database/securefiles/index.html . Performance information comparing Oracle SecureFiles with the file system is at http://www.oracle.com/technology/products/database/securefiles/perf.html .

Melli