Oracle blog – NIOUG

Securefiles in Oracle 11gR1 is a complete reengineered thing. Traditional lobs didn’t present so well themselves in the long run of business due to the limiation of their sizes and other factors which are pretty well documented in Oracle docs. So Oracle has given us in 11g Securefiles, LOBs on steroids if I can say so.
Well this blog post is not about Securefiles. Official docs do a pretty good job in explaining their working and other stuff and there are tons of other web sites which have done that already a good job explaining them eg you can read Tim Hall’s excellent article about the same here . This blog post is about a parameter that Oracle has given for the better working of Securefiles, yup correct, Shared_io_pool.
Shared_io_pool is added in the Oracle architecture to support large IOs. Normally large IO’s and if I can say, sort of like private IOs are best done using PGA with direct path access. When Securefiles are created with the options Cache which is actually borrowed from older cousin Basicfile aka LOBs only , they are read into the Buffer Cache which makes the access of these lobs more faster. This option is not there in Securefiles actually and hence is the reason for the 10g doc link. Using Buffer Cache is a good option but it has couple of issues as well. First and foremost is that due to the large size of lobs, they may go and kick the heck out all other tiny miny buffers from the buffer cache. Now if we are really using Lobs so we won’t mind doing this too I guess. But still, this can be not-so-good issue for the other small lookup table’s buffers which are thrown out. Another issue can be when we actually don’t use the Cache at all and go with plain, Nocache option which means , no buffer cache access. So now zero chance of any memory based access for lobs.
In 11g, for Securefiles, Oracle has tried to remove this issue with the introduction of Shared_IO_Pool parameter. This can be used as a shared region to support cached IOs for Securefiles. This parameter’s default size is mentioned as zero but I couldn’t find it as zero. I found it of actually some size. I guess the benefit is clear cut. As opposed to private memory given for PGA and to be allocated , this is a system level stuff so its more easy to give to everyone.
Lets see this parameter, starting from “normal” views

SQL> select  * from V$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE    11.1.0.6.0      Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

SQL> select pool,name,bytes from V$sgastat where lower(name) like '%shared%';

POOL         NAME                            BYTES
------------ -------------------------- ----------
             shared_io_pool                4194304

shared pool  SHARED SERVERS INFO              3108
             generic process shared st          12
             array 2 for shared redo b          96
             array 1 for shared redo b          96
             ksfd shared pool recovery          24

6 rows selected.

SQL> startup force
ORACLE instance started.

Total System Global Area  188313600 bytes
Fixed Size                  1332048 bytes
Variable Size             134220976 bytes
Database Buffers           46137344 bytes
Redo Buffers                6623232 bytes
Database mounted.
Database opened.
SQL> select pool,name,bytes from V$sgastat where lower(name) like '%shared%';

POOL         NAME                            BYTES
------------ -------------------------- ----------
             shared_io_pool                4194304

shared pool  SHARED SERVERS INFO              3108
             generic process shared st          12
             array 2 for shared redo b          96
             array 1 for shared redo b          96
             ksfd shared pool recovery          24

6 rows selected.

SQL>

The default of this parameter’s value in my system is coming out to be 4m. I am not sure that its actually correct or not. I shall install a vanila install of Oracle db and will recheck it. Let’s try to see a little more deeper about this parameter.
I blogged about learning a new trick to find the info about the fixed table structures some time ago. Using the same, let’s see what comes out for this parameter,

SQL> desc v$fixed_view_definition
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 VIEW_NAME                                          VARCHAR2(30)
 VIEW_DEFINITION                                    VARCHAR2(4000)

SQL> set long 500000
SQL> select view_definition from V$fixed_view_definition where view_name like 'V$SGASTAT';

VIEW_DEFINITION
--------------------------------------------------------------------------------
select  POOL, NAME , BYTES from GV$SGASTAT where inst_id = USERENV('Instance')
SQL> set long 500000000
SQL> select view_definition from V$fixed_view_definition where view_name like 'GV$SGASTAT';
VIEW_DEFINITION
--------------------------------------------------------------------------------
select inst_id,'',ksmssnam,ksmsslen from x$ksmfs where ksmsslen>1  union all  se
lect inst_id,'shared pool',ksmssnam, sum(ksmsslen) from x$ksmss    where ksmssle
n>1 group by inst_id, 'shared pool', ksmssnam  union all  select inst_id,'large
pool',ksmssnam, sum(ksmsslen) from x$ksmls    where ksmsslen>1 group by inst_id,
 'large pool', ksmssnam  union all  select inst_id,'java pool',ksmssnam, sum(ksm
sslen) from x$ksmjs    where ksmsslen>1 group by inst_id, 'java pool', ksmssnam
 union all  select inst_id,'streams pool',ksmssnam, sum(ksmsslen) from x$ksmstrs
    where ksmsslen>1 group by inst_id, 'streams pool', ksmssnam

So there are couple of fixed table structures which are involved here. The structure, X$KSMFS(Kernel Services , Memory Fixed SGA) shows the info of fixed value area in the sga which includes shared_io_pool also,

SQL> select ksmssnam,ksmsslen from x$ksmfs
  2  /

KSMSSNAM                     KSMSSLEN
-------------------------- ----------
fixed_sga                     1332048
buffer_cache                 46137344
log_buffer                    6623232
shared_io_pool                4194304

So the size shown here is also 4m only.
Let’s see how many other parameters are there related to this?

SQL> select ksppinm,ksppstvl,ksppstdvl
  2   from x$ksppcv a,x$ksppi b
  3  where a.indx=b.indx and b.ksppinm like '%shared_io%';

KSPPINM                        KSPPSTVL                       KSPPSTDVL
------------------------------ ------------------------------ ----------------
__shared_io_pool_size          4194304                        4M
_shared_io_pool_size           4194304                        4M
_shared_iop_max_size           536870912                      512M
_shared_io_pool_buf_size       1048576                        1M
_shared_io_pool_debug_trc      0                              0
_shared_io_set_value           FALSE                          FALSE

6 rows selected.

SQL>

So I guess the default size is indeed 4m only. I may be wrong so if you know some thing correct about this, do let me know and I shall correct it. It seems that this parameter can go maximumly to 512m. I am still searching for the other parameter’s description. Though look straight forward, I shall still wait to get the exact details about them before speaking about them.
Reading this article from Arup Nanda, it seems oracle has introduced some thing called Lob Cache specifically. Though I am not actually sure that there is some thing like this but it seems that this shared io pool is going to be lined with that in some way. It may be correct or may be not but this is my best guess about it so far.
It seems that Oracle has done some real thought-process before coming out with Securefiles. Let’s see what else we would see about them in future.
Aman….