1 / 18

OCCI Oracle C++ Call Interface

Detailed overview of Oracle OCCI C++ interface architecture, development cycle, common issues, and solutions. Explore key classes, utilities, and techniques used for schema handling and performance optimization. Learn about architectural dependencies, memory management, and debugging tools like mpatrol.

bdejong
Download Presentation

OCCI Oracle C++ Call Interface

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OCCIOracle 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

  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 0x0005738C 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: http://www.cbmamiga.demon.co.uk/mpatrol

More Related