DB2 Connect gebruik in een Microsoft omgeving Marc Cobbaert

Agenda SD Worx en haar DB2 achtergrond Huidige applicatie architectuur DB2 Connect opstelling Dynamic statement cache NIET: beveiligings- en applicatie aspecten

Situering SD Worx Sociaal secretariaat : dienstverlening op het vlak van loonadministratie en HR Voor KMO, Grote ondernemingen en de publieke sector Meer en meer internationaal georiënteerd Consultancy op vlak van HR, Tax & Legal, Rekrutering & Assessment, …. Kenniscentrum (marktstudies)

ICT omgeving van SD Worx 2 centrale datacenters in Antwerpen IBM mainframe Z9 BC X02 – z/OS 1.7 Windows 2003 gebaseerde decentrale servers (Windows cluster, VMWare, blades) Synchrone datareplicatie voor beide omgevingen 2 datacenters op 500m van elkaar gelegen Synchrone datareplicatie tussen beide gebouwen, zowel voor centrale (mainframe) als decentrale omgevingen (Windows 2003) IBM DS8100 systemen voor mainframe (PPRC) IBM DS4500/ IBM DS4800/ SUN D280 decentraal (IPSTOR datavirtualisatie)

DB2 historiek bij SD Worx DB2 gebruiker sinds 2001 gestart met DB2 V7 COBOL batch op het mainframe Dynamic sql vanuit een Windows omgeving RDBMS ervaringen met decentrale toepassingen op Oracle of MS Sql Server IDMS op mainframe - recent voorzichtig gebruik van stored procedures in COBOL (SP slechts spil van waaruit COBOL db2 routines worden aangeroepen) Wat is dynamic sql ? Applicatie perspectief : alles wat niet hardcoded in programma source staat; of maw. alles door gebruiker ingegeven of gegenereerd door apllicatie at run-time Db2 perspectief: alles wat niet vooraf is gebind en dus at run-time wordt ‘geprepared’ Bij Db2connect komt in eerste plaats dynamic sql in gedachten; kan natuurlijk ook static sql activeren (bv. in de vorm van SP of static packages, al of niet captured) Waarom dynamic sql ? Geen CICS achtergrond enerzijds, anderzijds vanuit Microsoft omgeving niet echt andere mogelijkheden, tenzij C of Java (SQLJ) met embedded sql Bij SD wordt ODBC/OLE-DB enkel via ADO of ADO.NET aangeroepen

Een paar DB2 mijlpalen … mei 2001 begin installatie aug. 2001 start in produktie feb. 2002 eerste produktie applicaties april 2002 synchronisatie data tss. IDMS en DB2 via MQ maart 2003 activering RLF juni 2003 Detector testen

Een paar DB2 mijlpalen … Aug. 2003 Gebruik realtime statistics Juni 2004 Extra accounting attributen Okt. 2004 eerste SP gebruik (COBOL) Apr. 2005 aanschaf Detector Aug. 2005 SMS managed tablespaces Nov. 2007 Websphere Replication Server for z/OS V9 Gebruik van realtime statistieken voor de opvolging van datagroei, reorganisatie momenten of bv. opsplitsing databankbuffers naargelang het UPDATE-gebruik Extra identificatie : eerste gebruik via SQLSETAPI gebruik (probleem met pooled connecties en rapportering) Send client information : - ClientAppName  DB2Connection.ClientApplicationInformation - ClientWrkstName  DB2Connection.ClientWorkstation - ClientUserid  DB2Connection.ClientUser - ClientAcctStr  DB2Connection.ClientAccountingInformation

DB2 Connect historiek bij SD Worx 2001: DB2 Connect V7 (9 fixpacks) MDAC 2.x, ODBC, OLEDB, ADO,.NET 1.0 2004: DB2 Connect V8 (5 fixpacks) ADO, ADO.NET, .NET V2.0 2006: DB2 Connect V9 (2 fixpacks) ADO.NET, .NET V2.0, V3.0 MDAC 2.5, 2.6, 2.7 : instabiliteit tussen releases, werking verschillend naargelang ODBC of OLEDB gebruik Worstelen met .NET ondersteuning, lange tijd geen officiële ondersteuning voor .NET vanuit IBM ODBC (1992) : 2.0, 3.x call level interface gebaseerd op werk van de X/Open groep, uitgebreid met MS specifieke extensies Object oriented data access methodes : DAO (data access objects)  JET Engine  ODBC RDO (remote data objects)  ODBC wrapper  ODBC ADO (ActiveX data objects)  OLEDB interface  ODBC/OLEDB native OLEDB (1996): - opvolger van ODBC, gebaseerd op COM - generieke data access API voor diverse datastores (RDBMS (ODBC), mail (MAPI), directory(LDAP)) - middleware die voorziet in een uniforme interface naar heterogene databronnen - programmeer model ADO (1996/97) : object layer bovenop OLEDB voor talen die geen pointervoorzieningen kennen (Visual Basic, Java, scripting) .NET en framework (v1.0 02/2002, v2.0 11/2005, v3.0 ??/2006) V9 omwille van V3 ondersteuning of V2 ?

Applicatie architectuur

Applicatie architectuur 3-tier applicaties gebaseerd op Microsoft technologie Web based applications Component based development (MTS/COM, COM+/.NET) Transaction monitor applications (COM+, MSDTC) XA-compliant resource manager dankzij DB2Connect

COM+ component services COM + voorziet in runtime services voor components ‘at runtime’ : Administration : MS Mgt Console Component Services Explorer (catalog) JITA : just-in-time activation (component activation/deactivation) Object pooling Transacties : distributed component acties als 1 transactie gegroepeerd (OleTX/XA)

COM+ Component Services Synchronization: controle over concurrent access naar objecten Role based security Queued components: asynchrone communicatie tussen componenten Events: signalisatie tussen componenten via publsh-subscribe mechanisme

Architectuur DB2 CLI API, noch ODBC of OLEDB worden rechtstreeks aangesproken MS-ADO interface wordt hiervoor gebruikt ADO is een object oriented data acess interface bovenop OLE-DB ADO is geëvolueerd naar ADO.NET die voorziet in zogenaamde managed data provider

Het MS .NET Framework .NET is een taal onafhankelijke omgeving voor het ontwikkelen van programma’s die op een eenvoudige manier kunnen samenwerken. De .NET programma’s draaien binnen de .NET execution runtime die abstractie maakt van onderliggende hardware of het operating systeem (vergelijkbaar met Java virtual machine). De componenten die de .NET omgeving vormen, noemt men het .NET Framwework. Dit framework bestaat uit 2 hoofdcomponenten : de Common Language Runtime (CLR) en de .NET Framework class library. De CLR vormt de basis van het .NET Framework en beheert de code op uitvoeringsniveau, waar het diensten als geheugenbeheer, thread beheer en remoting verzorgt, evenals stricte data types en beveiliging. Code die voor deze omgeving is ontwikkelt, noemt men managed code tov. unmanaged code.  performance impact ! Het andere onderdeel, de class library, is een object-oriented collectie van herbruikbare code (classes), interfaces en datatypes om applicaties mee te ontwikkelen. Zo bv. zullen .NET applicaties gebruikmaken van ADO.NET om relationele databanken als DB2 te benaderen en data hierin te manipuleren. De classes zijn georganiseerd in zogenaamde namespaces en iedere namespace is gerelateerd aan een specifieke functionaliteit, bv. namespace System.Data bestaat hoofdzakelijk uit classes die de ADO.NET architectuur vormen. System.Net verzorgen een eenvoudige API voor netwerkcommunicatie. IBM.Data.DB2 is namespace voor IBM DB2 .NET Data Provider.

Common Language Runtime MS .NET ondersteunt verschillende talen op het Microsoft platform, talen die moeten voldoen aan de Common Language Specification (een minimum set aan features waaraan desbetreffende compiler moet voldoen om te kunnen werken in de .NET runtime). Voorbeelden van MS zelf: Visual Basic .NET, C#, J# en Visual C++ en scripting talen als JScript.NET en VBScript. Source code wordt omgezet in MS Intermediate Language en at runtime door JIT compiler vertaald in Native machine code. De CLR is gebaseerd op een Common Type System (CTS), een verzameling ondersteunde data types, waardoor samenwerking van code geschreven in verschillende talen, eenvoudig mogelijk wordt. Vergelijkbaar met LE op mainframe.

MS ADO.NET ADO.NET helpt applicaties te connecteren naar een relationeel databanksysteem.

ADO.NET Architectuur Een DataTable object is een verzameling rijen uit één enkele databank tabel. Een Dataset is een collecties van DataTable objecten met relaties en constraints die de tabellen relateert. In disconnected mode is dit een in-memory relationele structuur waarop database operaties kunnen worden uitgevoerd (in memory-cache aan data gelezen uit databank). In connected mode is er directe interactie met de achterliggende databank. De DataAdapter is het object dat communicatie tussen DataSet en datasource mogelijk maakt en voert de DML statements uit Het Connection object wordt gebruikt om naar de databank te connecteren en kan gebruikt worden om transacties mee te controleren. Deze objecten zijn verschillende afhankelijk van gebruikte dataprovider, zo heb je een OleDbConnection en een ODBCConnection en IBM levert een DB2Connection object. Command objecten worden gebruikt om SQL Statements of Stored Procedures uit te voeren. De DataReader class wordt gebruikt om rijen van de databank in te lezen in je applicatie.

.NET Transactie beheer .NET 2.0 introduceerde nieuwe namespace  System.Transactions Lightweight transactions (single durable resource) OleTx transactions (distributed transactions, bv. multiple connecties naar multiple data stores) Voor lokale transacties (transacties naar 1 enkele databank of buiten COM+ beheer) bestaan er expliciete opdrachten binnen ADO.NET om transactie te starten (BeginTransaction()) en te beëindigen (Commit/Rollback). Data Access Laag en BusinessLogica Laag worden niet gescheiden gehouden  enkel voor kleinere applicaties Distributed transacties worden uitgevoerd door registratie binnen COM+. Resultaat van een transactie wordt imperatief bepaald in programmacode door SetAbort() en SetCommit() methoden of declaratief het door meegeven van AutoComplete attribute. (niet gebruikt)

SD WORX ervaring Integratie tussen Microsoft en IBM DB2 is sterk verbeterd en stabieler geworden Integratie in ontwikkelomgeving Eénduidige IBM DB2 .NET dataprovider Snelle evolutie in .NET blijft een aandachtspunt (.NET 3.0, 3.5, ondersteuning LTM) Performance aspect kan onder controle gehouden worden, maar is constant aandachtspunt (zie verder)

DB2 Connecties onderdelen Het netwerk (TCP/IP meestal) DB2 Clients (CLI, ODBC,OLEDB, DB2 .NET data providers) DB2 Connect server DB2 z/OS (DDF – netwerk connectiviteit / DBM1 database access threads) WLM Service classes en classification rules - in de huidige .NET wereld is de DB2 .NET data provider de aangewezen provider = managed ADO.NET data provider - Sneller dan bridge providers : als de OLE DB .NET data provider: stuurt request naar IBM OLE DB Provider (via COM interop module) of de ODBC .NET data provider: stuurt request naar IBM ODBC provider DB2Connect verzorgt 2 belangrijke elementen, nl. data APIs vanuit applicaties en communicatie met achterliggende DB2 subsysteem

Architectuur Belangrijk pooling (DB2Connect/DB2) Caching

DB2 Connect basis architectuur

DB2 Thread pooling

DB2 Connect Connection pooling

DB2 Connect concentrator pooling

DB2 z/OS Thread Pooling

DISPLAY THREAD DISPLAY THREAD(*) DISPLAY THREAD(*) TYPE(INACTIVE) Pooled DBAT NAME = DISCONN / STATUS = DA DISPLAY THREAD(*) TYPE(INACTIVE) Inactieve CONNECTIE informatie NAME = SERVER / STATUS =R2 DISPLAY DDF DETAIL DISPLAY LOC(*) DETAIL

Application pooling combinatie

Caching Dynamic sql processing bevat 2 stappen : Prepare Execute Prepare kan een zware operatie vormen : Parsen van SQL statement Valideren van de SQL syntax Cataloog access (tabellen, kolommen, privileges) Aanmaak access pad Aanmaak uitvoer statement - Cataloog statistieken benaderen (aantal rijen en pages, indexen en index levels, distribution statistieken, filter factoren berekenen, …)

Local Caching 4 vormen van caching : geen, local en global dynamic cache, full caching Zonder caching betaal je telkens prepare kost voor iedere statement (CPU en IO) Local cache : activering door BIND optie KEEPDYNAMIC(YES) – thread gebonden

Global Caching Global caching in de EDM POOL : DSNZPARM CACHEDYN=YES Alle DML die expliciet geprepared worden of aangeboden via EXECUTE IMMEDIATE Exacte SQL string matching en AUTHID Gebruik van parameter markers Consistente BIND opties bv. CURRENTDATA, ISOLATION, QUALIFIER

Full Caching Combinatie van local en global caching KEEPDYNAMIC(YES) MAXKEEPD > 0 CACHEDYN=YES

Types Prepare Full prepare: normaal geval bv. zonder caching Short prepare : skeleton copy of prepared statement gekopieerd naar local storage Avoided prepare : omwille van full caching Implicit prepare : DB2 voert impliciet prepare uit ten behoeve van applicatie (na COMMIT)

Dynamic statement cache CACHEDYN NO CACHEDYN YES KEEPDYNAMIC (NO) Geen enkele vorm van caching  enkel full prepares EDMP skeleton caching Short prepares mogelijk (YES) Geen skeleton caching  full prepares Impliciete prepares mogelijk (stmt. text bewaard over commit) EDMP caching Short prepares Prepared stmts bewaard  avoided prepares mogelijk NO caching: ieder statement moet full prepare ondergaan en kan dan pas worden uitgevoerd; na commit moet opnieuw full prepare worden doorlopen (geen enkele vorm van caching) aangezien prepared statement wordt vrijgegeven na COMMIT punt Onderscheid: skeleton, prepared statement, statement string LOCAL cache only (KEEPDYNAMIC only): telkens full prepare, maar SQL statement text wordt bijgehouden zodat DB2 een impliciete prepare kan uitvoeren – prepared statement nog steeds vrijgegeven na COMMIT GLOBAL cache only: eerste keer full prepare, skeleton SKDS wordt bijgehouden in EDM pool, prepared statement wordt vrijgegeven na COMMIT, evenals statement text  short prepare FULL CACHING : eerste keer fulle prepare, skeleton SKDS wordt bijgehouden in EDM pool, prepared stmt en sql text worden bijgehouden  avoided prepare SKDS = executable statement

DB2 DDF parameters Parm Waarde Beschrijving DDF AUTO DDF Startup at DB2 startup CMTSTAT INACTIVE THREAD POOLING CTHREAD 1-2000 Max. users MAXDBAT 0-1999 Max. remote active DDF – DBM1 CONDBAT 0-150000 Max. remote connecties - DDF POOLINAC 0-9999 Approx. Time in seconds that DBAT can remain in thread pool before terminating - opm. dit zijn niet uitsluitende DDF parameters (titel aanpassen ?)

DB2 DDF parameters Parm Waarde Beschrijving IDTHTOIN 0-9999 Idle thread timeout – iets hoger dan TCPKPALV TCPALVER NO TCP/IP allready verified user identification TCPKPALV 1-65534 TCP/IP keep alive – zie IDTHTOIN CONTSTOR YES/NO Periodieke “contract” thread’s working storage MINSTOR Storage mgt. Algoritmes gebruiken om thread’s working storage te minimaliseren - TCPKPALV detectie DB2 Connect gateways die verdwijnen, zodat DB2 geaffecteerde DBATS kan opkuisen TCPKEEPALIVE on DB2Connect server detecteert wanneer clients (PCs of applicatie servers) verdwijnen

DB2 en de Workload Manager WLM bepaalt de prioriteiten en kent resources toe (CPU, I/O, memory) WLM definities Binnenkomend werk (bv. DDF thread) krijgt service class toegewezen op basis van classificatie regels Een service class kan ingedeeld worden in perioden (inactive threads) Binnen een periode kunnen tegen een bepaalde prioriteit gelimiteerde resources verbruikt worden Dit kan beschermen tegen runaway queries

WLM Enclaves DDF threads worden uitgevoerd als enclave SRBs onder controle van WLM DDF classificatie binnen WLM is belangrijk om correcte thread priority te zetten Enclave creatie en vernietiging afhankelijk van CMTSTAT instelling Bij INACTIVE, wordt thread aangemaakt wanneer eerste SQL wordt ontvangen

WLM Enclaves Bij ACTIVE wordt enclave aangemaakt wanneer DBAT wordt aangemaakt Enclave verdwijnt bij INACTIVE bij COMMIT/ROLLBACK indien RELEASE(COMMIT) Enclave verdwijnt bij ACTIVE wanneer thread verdwijnt INACTIVE thread kan multi-period response time of velocity goals gebruiken

WLM Enclaves Bij ACTIVE kan enkel 1 periode velocity goal gebruikt worden Accounting info bij ACTIVE instelling, enkel wanneer thread eindigt Accounting info bij INACTIVE instelling op moment van COMMIT/ROLLBACK (met KEEPDYNAMIC(YES) in V8)

Diverse instellingen : decentraal Db2connect pooling (zie eerder) Max. agents / max. coordinating agenst Timeouts: applicatie/db2connect, client/db2connect server CONNECTTYPE/DISABLEMULTITHREAD/SYNCPOINT  MTS/COM+ CURSORHOLD=NO NT performance monitoring  DB2CONNECT_IN_APP_PROCESS=NO DB2_ENABLE_LDAP=N (snellere connect)