1. OCCI Oracle C++ Call Interface
Krzysztof Nienartowicz
DB Workshop
January 29-31, 2002

2. Overview Architectural overview Occi typical usage, development cycle
Issues to solve, problems
Tools, techniques used to understand OCCI internals

3. General Architecture overview
Associative ODMG like access using Ref<>
OCCI is a wrapper on top of OCI and Oracle internal calls
Set of C++ base classes, utility classes
templates
binary libraries

4. Architectural overview. cont.
OCCI is composed of ~ 25 classes + 30 classes of Oracle Data Cartridge Interface (ODCI) definitions for schema handling
Ref<> access and root PObject classes act as a interface with hidden implementation delegated to RefImpl and PObject binary packaged
plus utility classes to handle oracle native types
Connections, db environment

5. Architectural overview. cont.
innerNode as a user type. N1,..,N10 are private innerNode_C members
Access via get, set or as a public ones, OTT dependent

6. Architecture overview, cont. 2
STL dependencies
Binary and string types represented as STL std::vectors and std::strings
May hit the performance if a conversion (due to type casting) is done under the hood
No difference between const and non-const access patterns

7. Typical, application flow
Cache size implications, also to remark on prefetching,

8. OCCI Development cycle
DDL driven, one must have DB schema defined first
Two main cycles with given approach
Schema definition, schema tuning phase
Standard 3gl object oriented methodologies for the latter phase

9. OCCI Development cycle, 2
Schema definition - DDL/SQL

10. OCCI Development cycle, 3

11. OCCI Development cycle, 4

12. Occi current problems, issues, tweaks
Oracle production/bug fix cycle dependency
Ball on the Oracle side:
Small leaks escalation, cache settings dependent
Ref<> const, internal memory initialisation problems
Prefetching problems
Users’ responsibility to delete embedded objects
Unnamed exceptions thrown sometimes, segmentation faults instead of exceptions occur

13. Bloating memory (cache?) problem
Memory consumption of a trivial, very small object linked list iteration
Appears for many accesses for certain cache settings
Memory growth is access related not accessed objects’ size related
Benchmarking consequences…

14. Occi memory problems detection
“Unistd.h” sbrk(0) very helpful
mpatrol package
Mpatrol, mptrace, mprof
Dynamic hooks to the OS (libc, stdc++) memory calls with no code changes, recompilation on UX
Sophisticated memory monitoring, profiling with logging and post mortem analysis

15. Mpatrol usage Memory graphical profiling with mprof
Visual tracing with mptrace
Textual form, calls’ graph
Memory leaks, resizing, deleting, allocating stats

16. mpatrol
Easier tracing down of inefficiencies, in example beneath, extracted dereferencing of the app object.

17. Other mpatrol benefits
MEMSET: memset (0x002240C8, 68 bytes, 0x00) [-|-|-]
0xFEE72F34 kghualloc+600
0xFED0B20C kohalmc+480
0xFED0B020 kohalc+1836
0xFEA0D63C kadlal+80
0xFEDACFC8 kopldsgen+40
0xFEA15DB0 kadgscval+228
0xFEA15614 kadattrget+4396
0xFE9A39C0 OCIAnyDataAttrGet+68
0x000A14A0 oracle::occi::Number occi::AnyDataImpl::getNumber()const+104
0x00064E58 void innerNode_C::readSQL(oracle::occi::AnyData&)+32
0x00064D20 void*innerNode_C::readSQL(void*)+192
0xFECF3750 kodpunp+3700
0xFED02794 kocdsun+460
0xFECF6F7C kocgpn2+2720
0xFECF64D4 kocgpn+80
0xFED32B48 OCIObjectPin+3872
0x00088F94 oracle::occi::PObject*oracle::occi::RefImpl::pin()+168
0x0005F204 innerNode*oracle::occi::Ref<innerNode>::operator->()+44
0x0005C37C long BenchApp<long>::CheckInnerCycle(…)+212
0x000578D0 void BenchApp<long>::DoRead()+720
0x C int BenchApp<long>::Run()+52
0x0005F78C main+92
Occi internals quasi–debugging, i.e. allows to understand occi-oci-oracle layering better

18. Summary
The Ref<> associative access the main OCCI advantage in comparison to other methods
Waiting for the next release to proceed with benchmarks
Cache handling improvement
Bugs to be removed
Inconsistencies to be removed (i.e. ott naming)
For mpatrol check: