Processing 1.5MB file generates 940MB increase in BizTalkMsgBox

We have a file containing 10,000 records, each record is 155 characters and consist of fixed length fields. There are no header or trailers. I have created a process that converts each message into a XML message and puts it into a MQSeries queue.

1) Receive Location using the FILE transport type looks for a file in a specific directory (c:\jeff\LM*) and passes it to a custom pipeline

2) Custom pipeline uses the Flat file disassembler and references a schema created with the flat file extentions.

3) The flat file schema uses a Child Delimiter (0x0D 0x0A) and the order is postfix.In the schema editor it looks like

<Schema?

     TheRequirement          Delimited

          Requirement          Positional        0       155

          <Sequence>          Positional        0       155

               Date                 Positional        0       7

               BuyCode          Positional        7        1

               NSN                Positional        8        15

 and do on until all the fields are defined.

4) A Send Port using the MQSeries adapter is configured to write to a queue using the passthru default pipeline and a filter (BTS.ReceivePortName == Split_Receive_Port)

This works well and generates one XML message for each line in the file. The problem is that running 10,000 records through the process, the 1.5 MB file results in an increase of the BizTalkMsgBoxDb by 241 MB and the BizTalkMsgBoxDb_log by 669 MB. It appears that all this disk increase occurs during the Receive Port processing. It takes about 10:47 (10 minutes 47 seconds) for the file to disappear out of the directory in which no messages are being written to the MQSeries queue. Once the file disappears from the directory, messages start showing up in the queue. During this 10:47 all the increase in the DBs are taking place. During the time to put the 10,000 messages into the queue, the database does not increase by any noticable amount. It takes about 14:39 to put all 10,000 messages into the queue.

I would appreciate any thoughts you may have.