Advice about why not setting multi-block sizes

Hi Lex,
If you can helpme to understand please

> I repeat that this is a *bad* advice, regardless whether your database is very
> big or very small.
> there are better ways to influence cache performance/behavior, without the
> disadvantages of multiple block sizes and a segmented buffer cache. a segmented
> cache needs constant attention and (re)configuration, and even then it always
> leads to suboptimal shared memory usage.

My logic goes in this way, I have different system on the same database. One is an accountatn sytem and other is a software production system.

• BLOB 32K TABLESPACE In the software production system therei s a table where I store in blobs all the fmb and rdf,

The accounting sytem has configured their buffers. If I create a different tablespace of 32K only for that table(table storing blobs), i think:
1) this is not going to bother memory configuration of accounting system. 2) this will improve reads, because forms and rdfs are big, bigger block size will be better.
3) This allows me to set a reduced memory to that units, for example I don't want oracle use 100 MB for this table, I want only to use 20MB, so I can restring more efficiently the memory for that specific table.

Now this table is used for few users(10), several times a day. not too frequently.

• INDEX 16K TABLEPACE Our market is small, our tables are small, our system is fast enough. We have few customers, we don't have time to optimize every singly form we do, because we don't have time, and beacuse we don't need it. If we detect some performance problem we solve it, and the overal performance is ok. We use a good common sense design, and everything works ok.

I moved all indexes to a different tablespace for recovery purposes, this means if some day a block is damaged and this block is in the index tablespace, and there is no way to recreate it, I know I can recreate the tablespace and reindex, everything and all is ok.

I use a 16k block size because
1) 16k blocksize is better for index access. 2) I can reserve memory only for indexes, so I can give more memory for index access, because most of access are through indexes, not through full-scans.
I can't optimize database per database, some customers have 4 database in the same server. So what I want is to guarantee an area for indexes. They use virtual memory and this works ok for them, they don't want to buy another server, they are happy so, finally is a small database.

Please Lex, could you helpme to, explaining your position about it: Why is wrong, how should I do that.

Thanks a lot for your advice.

--
http://www.freelists.org/webpage/oracle-l