Split CLOB column to improve performance

Question

Hi All,
We have a transactional table which has 3 columns and one among those is CLOB which holds XML data.Inserts are coming at 35K/hr to this table and data will be deleted as soon as job is completed. So anytime the total records in this table will be less than 1000.
The XML data contains binary info of images and the size of each XML file ranges any where between 200KB to 600KB and the elapsed time for each insert varies from 1 to 2 secs depending upon the concurrency. As we need to achieve 125K/hour soon we were planning to do few modifications on table level.
1. Increase the CHUNK size from 8KB to 32KB.
2. Disabling logging for table,clob and index.
3. Disable flashback for database.
4. Move the table to a non default blocksize of 32KB. Default is 8KB
5. Increase the SDU value.
6. Split the XML data and store it on multiple CLOB columns.
We don't do any update to this table. Its only INSERT,SELECT and DELETE operations.
The major wait events I'm seeing during the insert is
1. direct path read
2. direct path write
3. flashback logfile sync
4. SQL*Net more data from client
5. Buffer busy wait
My doubt over here is ,
1. If I allocate a 2G memory for the non default block size and change the clob to CACHE, will my other objects in buffer_cache gets affected or gets aged out fast?
2. And moving this table to a SECUREFILE from BASICFILE will help?
3. Splitting the XML data to insert into different columns in the same table will give a performance boost?
Oracle EE 11.2.0.1,ASM
Thanks,
Arun

Answer 1

Thanks to all for the replies
@Sybrand
Please answer first whether the column is stored in a separate lobsegment.
No. Table,Index,LOB,LOB index uses the same TS. I missed adding this point( moving to separate TS) as part of table modifications.
@Hemant
There's a famous paper / blog post about CLOBs and Database Flashback. If I find it, I'll post the URL.
Is this the one you are referring to
http://laimisnd.wordpress.com/2011/03/25/lobs-and-flashback-database-performance/
By moving the CLOB column to different block size , I will test the performance improvement it gives and will share the results.
We dont need any data from this table. XML file contains details about finger prints and once the application server completes the job , XML data is deleted from this table.
So no need of backup/recovery operations for this table. Client will be able to replay the transactions if any problem occurs.
@Billy
We are not performing XML parsing on DB side. Gets the XML data from client -> insert into table -> client selects from table -> Upon successful completion of the Job from client ,XML data gets deleted.
Regarding binding of LOB from client side, will check on that side also to reduce round trips.
By changing the blocksize, I can keep db_32K_cache_size=2G and keep this table in CACHE. If I directly put my table to CACHE, it will age out all other operation from buffer which makes things worse for us.
This insert is part of transaction( Registration of a finger print) and this is the only statement taking time as of now compared to other statements in the transaction.
Thanks,
Arun