LIBCELL in its name tells us that LIB stands for library and CELL stands for storage cell

LIBCELL acts as a liquid layer which has the source code that allows the oracle kernel to communicate to the storage cells using network protocol called RDS(reliable datagram sockets)

Do you know that there is small library file used in exadata machine which is the core library which speaks with the iDB(intelligence database protocol)/RDS to get the data from storage cell

Let us get some practical insights from the machine

Locate to cell home and point to lib directory

[root@exceladm00 lib]# env|egrep 'OSS_HOME|LD_'

LD_LIBRARY_PATH=/opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib
OSS_HOME=/opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv

Below is the libcell file which we look for!

[root@exceladm00 raw]# locate libcell
/opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib/libcell11.so

Lets read the content of the file for insights

[root@exceladm00 ~]# strings /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib/libcell11.so > libcell

There are set of kernel parameters and error codes inside the file

This Libcell file actively interacts between kernel in the OS layer and storage layer and has the intelligence to ask for the data from storage cells via iDB which is required by the database or end user

[root@exceladm00 ~]# head libcell && echo "=================================================" &&tail libcell
_DYNAMIC
_GLOBAL_OFFSET_TABLE_
__gmon_start__
__cxa_finalize
_Jv_RegisterClasses
dbgc_get_gp
kgefac_
kgeasnmierr
__assert_fail
dbgdChkEventInt
=================================================
^^^^^^^^Error:  Buffer overrun occurred, forced exit
^^^^^^^^Initialization of symbol handler failed. Error code %d
^^^^^^^^RtlCaptureContext function not found in ntdll.dll
^^^^^^^^StackWalk is terminated abnormally. Error code %d
^^^^^^^^Exception is raised during stack walking
^^^^^^^^Signal %s is raised at 0x%p
^^^^^^^^Intel(R) Pentium(R) M and compatible Intel processors
^^^^^^^^Fatal Error: Can not initiate the Heap
basic
disabled

Lets view the process

[root@exceladm00 ~]# lsof|grep libcell
cellrssrm  4312      root  mem       REG                8,1  1717370     587643 /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib/libcell11.so
cellrssrm  4321      root  mem       REG                8,1  1717370     587643 /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib/libcell11.so
cellrssrm  4322      root  mem       REG                8,1  1717370     587643 /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib/libcell11.so
java       4323      root  mem       REG                8,1  1717370     587643 /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib/libcell11.so
cellrsbkm  4324      root  mem       REG                8,1  1717370     587643 /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib/libcell11.so
cellrsbkm  4339      root  mem       REG                8,1  1717370     587643 /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/lib/libcell11.so

Lets take a close look at trace for libcell process during a sql transaction and observe the insights from it

I triggered a select statement and grabbed the pid from the session for libcell

we can see lseek () system call which has the file pointer and increment the seek set from 0 to 512

we observe read() and write() system call which performs the data read from storage cell and write it to the buffer

Libcell constructs the sql statement over iDB/RDS and requests the data from the storage layer

you can observe the db block size as 8208 in the read system call which is shown in trace

 
    0.000000 read(11, "\2s\0\0\6\0\0\0\0\0\20\27\0\0\0U5gd\307M\272n|XU\315%\36\304\327x"..., 8208) = 627
  6171.714101 write(10, "\0\25\0\0\6\0\0\0\0\0\3\5y\3\0\0\0\17\0\0\0", 21) = 21
     0.000222 read(11, "\2\200\0\0\6\0\0\0\0\0\6\1\2\263\4\0\0\0\0\0\17\0\0\0\0\0\0\0\0\0\0\0"..., 8208) = 640
     0.000216 open("/data/oracle/11.2.0/db_home/rdbms/mesg/oraus.msb", O_RDONLY) = 9
     0.000141 fcntl(9, F_SETFD, FD_CLOEXEC) = 0
     0.000093 lseek(9, 0, SEEK_SET)     = 0
     0.000093 read(9, "\25\23\"\1\23\3\t\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 256) = 256
     0.000121 lseek(9, 512, SEEK_SET)   = 512
     0.000087 read(9, "f\31\2603gJ>h\265z\342\207C\226]\310m\374\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
     0.000107 lseek(9, 2560, SEEK_SET)  = 2560
     0.000085 read(9, "\241J\254J\264J\270J\273J\275J\277J\301J\303J\306J\312J\315J\321J\332J\340J\351J"..., 512) = 512
     0.000105 lseek(9, 486912, SEEK_SET) = 486912
     0.000126 read(9, "\v\0\27_\0\0J\0\30_\0\0e\0\31_\0\0\203\0\32_\0\0\254\0\33_\0\0\324\0"..., 512) = 512
     0.000121 close(9)                  = 0
     0.000134 write(10, "\0\25\0\0\6\0\0\0\0\0\3\5z\3\0\0\0\17\0\0\0", 21) = 21
     0.000193 read(11, "\2k\0\0\6\0\0\0\0\0\6\0\2\263\3\0\0\0\0\0\17\0\0\0\0\0\0\0\260\255l\371"..., 8208) = 619
     0.000072 write(10, "\0\25\0\0\6\0\0\0\0\0\3\5{\3\0\0\0\17\0\0\0", 21) = 21
     0.000363 read(11, "\2b\0\0\6\0\0\0\0\0\6\0\2\263\3\0\0\0\0\0\17\0\0\0\0\0\0\0\260\255l\371"..., 8208) = 610
     0.000212 write(10, "\0\25\0\0\6\0\0\0\0\0\3\5|\3\0\0\0\17\0\0\0", 21) = 21
     0.000189 read(11, "\2\200\0\0\6\0\0\0\0\0\6\0\2\263\3\0\0\0\0\0\17\0\0\0\0\0\0\0\260\255l\371"..., 8208) = 640

The contents shown in this article are just for general audience for understanding purpose and not standard operation procedure.Never ever try this in a production machine