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