Thanks Tom, so I think I understand this now. The additional dictionary cursors I am seeing are the sequence updates that occur every time we need to get a new sequence cache set, so in my raw trace file I find 2,002 update statements as I did the transaction 10,000 times with 4 sequences each with a cache of 20 (not sure what the odd 2 were for but close enough).
I can see from the raw trace that the cursor is parsed, exec and closed. So what I see in v$open_cursor are the old cursors for the same sql_id that have not been cleaned out util I hit the cached cursor limit.
PARSING IN CURSOR #139665827233920 len=129 dep=2 uid=0 oct=6 lid=0 tim=1332977279328919 hv=2635489469 ad='de6e3078' sqlid='4m7m0t6fjcs5x'
update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10 where obj#=:1
END OF STMT
STAT #139665827233920 id=1 cnt=0 pid=0 pos=1 obj=0 op='UPDATE SEQ$ (cr=1 pr=0 pw=0 time=55 us)'
STAT #139665827233920 id=2 cnt=1 pid=1 pos=1 obj=79 op='INDEX UNIQUE SCAN I_SEQ1 (cr=1 pr=0 pw=0 time=3 us cost=0 size=68 card=1)'
The bit I'm still not quite sure of is why I see an improvement when I increase the SCC parameter from 150 to 500, my app only needs 130. I'll run some tests and tkprof them to see where I am getting the saving. Does the sequence update not benefit from a softer soft parse by the fact there are copies of the sql in the session cache. Are cursors discarded by their cursor type or are they all treated by the same LRU logic and simply by the fact a cursor has had a hit it goes to the top of the list.
As always thanks for your help. I know a little bit more about this vast subject.