in Baden-Wuerttemberg
Transcription
in Baden-Wuerttemberg
KM-EWO Resident Registration and Information System An Oracle 11.2.0.3.0 success story © Datenzentrale Baden-Württemberg 1 May I introduce myself ? Name Georg H. P e t e r Diplom-Finanzwirt (FH) Company Datenzentrale Baden-Wuerttemberg Department Product Support Knowledge Center Database Systems Address Krailenshaldenstraße 44 D-70469 Stuttgart Germany +49-711-8108-27271 +49-711-8969-6071 [email protected] http://www.datenzentrale.de PC-Fax e:mail Internet © Datenzentrale Baden-Württemberg 2 Who am I? I am a database administrator within Datenzentrale Baden-Wuerttemberg and responsible for database design, data validation and security procedures, data recovery, performance monitoring and tuning. D And last, but not least I am co-responsible for the general administration of the whole database software environment in my company. Beyond this I work together with my collegues in our IT centers in Baden-Wuerttemberg as well with a number of IT centers in Germany. © Datenzentrale Baden-Württemberg 3 I am working with Oracle 11g since 2009. Back in the dark ages I was an application programmer. And long ago, when knights were bold, dragons walked the earth, and Oracle and DB2 were born and I was young, I worked with Adabas C and later on with DB2 z/OS... I‘ve also served on several technology forums and boards like - International DB2 Users Group (IDUG®) - DB2 G.U.I.D.E., - BMC Software Roundtable - CA german and european User Groups - Oracle PartnerNetwork - and today © Datenzentrale Baden-Württemberg 4 © Datenzentrale Baden-Württemberg Datenzentrale's customers in Baden-Wuerttemberg: 9 major municipalities 35 major administrative districts 1.060 (!) towns and small communities 5 © Datenzentrale Baden-Württemberg Our job ? Service and support for applications in seven regional data centers. Development of applications with the aim of creating "uniform processes throughout the entire State of Baden-Wuerttemberg“. "The" IT development centre for the State of Baden-Wuerttemberg, Germany. 6 Our data centers in Baden-Wuerttemberg Datenzentrale Stuttgart Regional data centers: Heidelberg Heilbronn Karlsruhe Stuttgart Reutlingen Ulm • KIV BF •Karlsruhe •Freiburg •Heidelberg •Heilbronn • KDRS •Stuttgart • KIRU •Reutlingen •Ulm Freiburg We cover 95 % of the small and major municipalities and administrative districts in Baden-Wuerttemberg 7© Datenzentrale Baden-Württemberg 7 Land SH Dataport Land MV Land HH Land HB Customers inside and outside Baden-Wuerttemberg e.g. in Brandenburg Bremen Hessen Lower Saxony Rhineland-Palatine Saxony-Anhalt Thuringia Land ND Land Berlin Osnabrück Citeq Münster Herne Bielefeld KDVZ Citkomm Land BB Land ST Halle KRZ Niederrhein Wuppertal eKom21 BMBF TLRZ Land TH Leipzig KISA Cottbus /KIRU Land SN Dresden Limbach-Obf. Land RP Mainz Trier Nürnberg ZDV Saarland Saarbrücken Land BW KIV BF KDRS KIRU © Datenzentrale Baden-Württemberg 8 Tell me why ... Walkin' down the floor You look into a dump You look into a dump and you say Whywhywhy whywhywhy……. Or in other words: Today, the need to modernize applications is clear as we struggle with the rising costs and degreased business agility associated with legacy IT landscapes….. © Datenzentrale Baden-Württemberg 9 Additional we got faced with the limits of EBCDIC in DB2 for z/OS. Starting with DB2 z/OS for more than 20 years we had only data that can be stored in EBCDIC tables. Two decades later we have not only german data to store but also data from all over the world and therefore we got faced with the limits of EBCDIC. © Datenzentrale Baden-Württemberg 10 And if I ask Oracle how they handle different CCSIDs in one table (UNICODE and EBCDIC for example) – they will answer “just define your additional UNICODE-column and that is nearly all”. Nearly all ? One thing to mention is that you have to calculate the now needed disk space of your application data in the future..... And if I ask the DB2 experts how to expand a local EBCDIC world into a international UNICODE world, they will tell me several limiting factors immediately: - Within one table it is not possible to use different CCSIDs ! - It is not possible to use different CCSIDs in one space set ! - And there is another upcoming big challenge……….. © Datenzentrale Baden-Württemberg 11 We all know that staffs are being squeezed today, and fewer DB2 z/OS people are doing the same work or more. One person on the staff, your friendly DBA, has more to do than there is time for. Additionally, many of the existing DB2 DBA‘s are retiring and are being replaced by younger people who don't have the many years experience of the retiring DB2 z/OS staff…………. © Datenzentrale Baden-Württemberg 12 Challenges 1. Reduce cost 2. Have only one database system 2. Reduce the overall time for administration 3. Provide an IT platform capable of tight integration with other legacy systems 4. Guarantee stability and flexibility of the IT infrastructure 5. Provide easy, quick, and secure information access 6. Last but not least: UNICODE © Datenzentrale Baden-Württemberg 13 Okay, determining where and how to begin the modernization of a special application can be daunting. Anyway– we tried the modernization journey…… © Datenzentrale Baden-Württemberg 14 We started our „old“ resident registration and information system in 1992/1993. The application was mainframe-based (Cobol, CICS) and the DBMS was IBM‘s DB2 for z/OS. Because of Java and some other good reasons (e.g. money, money, money ;-) the time has come to put the workhorse to sleep. And we decided to rewrite the application. And the new DBMS is – surprise, surprise – © Datenzentrale Baden-Württemberg 15 of the „old“ application DB2 Object Count Databases Tablespaces Tables User views Indices Foreign Keys SQL-Statements Packages DBRM‘s 33 37 227 322 287 34 13092 1590 352 Total 15974 © Datenzentrale Baden-Württemberg 16 The old application (Cobol, CICS, DB2 z/OS) was divided into four major areas. We decided to redesign/ develop all four areas of the application with Java and Oracle 11g. © Datenzentrale Baden-Württemberg 17 Platform Decision © Datenzentrale Baden-Württemberg 18 Technology „Service-oriented architecture“ © Datenzentrale Baden-Württemberg 19 Logical Architecture for KM-EWO Front-End Platform UserFacing Software SOA Platform (Backplane) Composite Services Application Services Data Services Back-End Platform Business Data Service-Oriented "Enterprise" © Datenzentrale Baden-Württemberg 20 Physical System Architecture Photo Courtesy: KIVBF © Datenzentrale Baden-Württemberg 21 Used hardware in development Development Server Windows Server 2003 R2 Standard x64 Edition Demonstration Server Reference Server (used for Rollout and Test) Windows Server 2008 Standard x64 Edition e.g. for potential customers or for use at conferences Windows Server (R) 2008 Standard Server 6.0 Service Pack 2 (64-bit) VMware Virtual Platform © Datenzentrale Baden-Württemberg 22 And so we ended up with the new application Oracle-Object Count DATABASE LINK FUNCTION INDEX LOB MATERIALIZED VIEW PACKAGE PACKAGE BODY PROCEDURE SEQUENCE TABLE TRIGGER TYPE TYPE BODY VIEW 3 3 310 17 14 54 54 6 1 171 82 2 1 5 © Datenzentrale Baden-Württemberg 23 And so we ended up (ctd) That means we migrated 227 DB2 z/OS tables into now 171 Oracle 11g tables on a windows platform. A special team in the project wrote all the migration programs. These programs are not only simple data loaders, they also cover things like data quality control and data cleaning, conversions and transformations, etc. etc. We used these home-grown programs in our tests and also for the real-life-migration of the existing 10.486.660 residents in BadenWuerttemberg. And the overall migration process went very well ;-) © Datenzentrale Baden-Württemberg 24 Lessons we learned From a performance perspective, Oracle 11g Enterprise Edition is really great. We’re actually running Oracle 11g R2 on standard commodity servers, so we have plenty of room to grow. © Datenzentrale Baden-Württemberg 25 Lessons we learned (Ct‘d) Oracle is a flexible and robust database – but along with a great power comes great complexity. This complexity requires that the DBA has expert knowledge of Oracle internals. Strong DBA resources are a must. But detailed coverage of these features is beyond the scope of this presentation……… © Datenzentrale Baden-Württemberg 26 Lessons we learned (Ct‘d) In terms of learning Oracle, this is getting easier all the time as the DBMS features merge across platforms. As a DB2 z/OS DBA, I understand how to manage data: performance, security, recovery, administration, etc. This knowledge and experience is valuable for any DBMS. All of the facilities are there in Oracle; I had to spend some time to learn them, but I know what to look for ;-) © Datenzentrale Baden-Württemberg 27 Lessons we learned (Ct‘d) For me as a DBA it took some time to become conversant with Oracle. Oracle is a great product and well worth learning. It is like Tom Kyte said: “Knowledge comes with experience and experimentation”. On the other hand: When you look at the tasks that have to be done in Oracle also: - bad SQL is still bad SQL - space management is still required - archive log management is still required - capacity planning is still required - OS tuning is still required etc. etc. © Datenzentrale Baden-Württemberg 28 Lessons we learned (Ct‘d) We tested (and love) Table Compression As our new online transaction processing (OLTP) database grew in size to terabytes, we recommended to use table compression. Why ? Table compression is completely transparent to our application. And table compression saves disk space and reduces memory use in the buffer cache. And it seems that table compression sometimes speeds up query execution during reads. (less I/O?) On the other hand there is a very small cost in CPU overhead for data loading and DML. © Datenzentrale Baden-Württemberg 29 Lessons we learned (Ct‘d) DELETE from table versus TRUNCATE TABLE In some cases (e.g. fast growing tables during mass tests) we had the requirement to delete all the test data after a successful run of such a mass test. First we tried DELETE FROM TABLE…. But this deletes perform normal DML/Logging. That is, they take locks on rows, they generate redo (lots of it), and they require segments in the UNDO tablespace. If a mistake is made a rollback can be issued to restore the records prior to a commit. So far so good. © Datenzentrale Baden-Württemberg 30 Lessons we learned (Ct‘d) DELETE from table versus TRUNCATE TABLE (ct‘d) But a rollback was not the goal. And here TRUNCATE comes into the game. Truncates are DDL and a truncate moves the High Water Mark of a given table back to zero. No row-level locks are taken. No redo or rollback is generated. This DDL command has the same effect as a DELETE, but without all the overhead. Slight problem: A truncate is a DDL command, so you can't roll it back if you decide you made a mistake. Truncate issues a COMMIT before it acts and another COMMIT afterward so never a rollback of the transaction is possible. ….. © Datenzentrale Baden-Württemberg 31 Lessons we learned (Ct‘d) Oracle is a complex database system and there are hundreds settings that can be sub-optimal and cripple the overall database performance. If changes are required: Just handle the requirement (in a lot of cases even on the fly) without changing the application. It is critical to identify all database bottlenecks to ensure that a mission critical system is running at optimal speed. © Datenzentrale Baden-Württemberg 32 Lessons we learned (Ct‘d) Normally you can find the SQL performance elephants - those statements that rampage through your instances consuming excessive amounts of valuable resource. But there are other performance challenges which are not so easy to find – I call them the “SQL mosquitoes”. These seemingly insignificant SQL normally consume very little in the way of CPU or storage. But if these SQL mosquitos are executed thousands or millions of times, each time adding another small piece to your performance nightmare…... © Datenzentrale Baden-Württemberg 33 Lessons we learned (Ct‘d) For those challenges we found out that two features in Oracle are very helpful to identify potential performance bottlenecks. The Automatic Workload Repository (AWR) The Automatic Database Diagnostic Monitor (ADDM) Best of all: AWR and ADDM are parts of the Oracle database software. But: A licence is needed….. Why best of all? Within DB2 z/OS there was no comparable software. We had to use a third party vendor product for these challenges ;-( © Datenzentrale Baden-Württemberg 34 Lessons we learned (Ct‘d) Oracle Dynamic Performance Views (V$-Views) This set of virtual tables - that record current database activities - are very helpful for an Oracle DBA like me. There was/is nothing like this in DB2 z/OS. A DBA can select from these views, but he should never update or alter them……. © Datenzentrale Baden-Württemberg 35 Lessons we learned (Ct‘d) Patching is often a tedious process Can break functionality Patches appear released without thorough testing We had to learn the “game” of Support Service Request Management turn around Responses sometimes appear like delay tactics Escalation methods must be learned and mastered © Datenzentrale Baden-Württemberg 36 Lessons we learned (Ct‘d) A DBA can perform typical administrative functions faster using Oracle Database 11g compared to IBM DB2 z/OS. For example Enterprise manager……. Oracle Database 11g requires fewer steps for the same set of standard RDBMS tasks than IBM DB2 z/OS. Example sql developer……. Benefiting from increased DBA productivity due to lower complexity and higher efficiency, businesses could save a lot of money per year per DBA by using Oracle Database 11g over IBM DB2 z/OS. © Datenzentrale Baden-Württemberg 37 Lessons we learned (Ct‘d) On the other hand: If you want to plow a field with a lot of chickens (Oracle instances) instead of one mule (DB2 for z/OS), then - yes the unit cost per chicken is less - but herding chickens becomes the new frontier for you. © Datenzentrale Baden-Württemberg 38 Lessons we learned (Ct‘d) Recovering a single tablespace is the lowest logical recovery unit in DB2 z/OS….. In Oracle the lowest logical recovery unit is a table. Additional in Oracle the flashback database mechanism provides any detail of transactional history (even for row level units) with a clear and powerful interface. © Datenzentrale Baden-Württemberg 39 Lessons we learned (Ct‘d) DB2 z/OS static SQL is generally pre-compiled into plans and packages of compiled access paths, while Oracle always uses dynamic SQL compilation. Another goody in Oracle are SQL profiles. These alternative execution plans are easy to use and manage with the help of the automatic tuning advisor. SQL Profiles are stored persistently in the data dictionary, so it does not require any application code changes (you never have to touch the SQL statement itself). When such an SQL statement is executed, Oracle detects that a SQL profile exists for this statement, and the optimizer automatically changes the execution plan. © Datenzentrale Baden-Württemberg 40 Migrating from DB2 z/OS to Oracle 11G R2: For us and our production data centers a real great success story! For more information (in german language) please take a look at http://www.datenzentrale.de/site/Datenzentrale-Internet/get/6030236/KM_Ewo_K21_04_2014.pdf https://emeapressoffice.oracle.com/Press-Releases/Datenzentrale-Baden-W%C3%BCrttemberg-setzt-weiter-aufOracle-4707.aspx http://www.datenzentrale.de/site/Datenzentrale-Internet/get/7082412/KM_Ewo_K21_2014_08.pdf © Datenzentrale Baden-Württemberg 41 KM-EWO Oracle © Datenzentrale Baden-Württemberg 42 KM-EWO Oracle Rainers knowledge of Oracle is immense and he constantly shared this experience, both in his "day job" supporting the Oracle database products and in his involvement with user groups (especially the DOAG regional meeting in Karlsruhe where he was and is a presenter for many years). In Baden-Wuerttemberg he is a well-known Oracle expert with a very deep insight into all facettes of e.g. Oracle database software. When we work together we really apreciate his style of communication and his very precise style of working. © Datenzentrale Baden-Württemberg 43 This is the end….. © Datenzentrale Baden-Württemberg 44