POUG Workshop - nowy format konferencji

03.07.2020, Warsaw


POUG czyli Polish Oracle User Group to społeczność, która powstała z inicjatywy firmy Database Whisperers w 2016 roku. Po serii udanych meet-upów i czterech dwudniowych, międzynarodowych konferencjach przyszedł czas na nowy format - POUG Workshop.

Wiemy, że zabrzmi to jak marketingowy bełkot, ale pomysł nowego wydarzenia to faktycznie odpowiedź na Wasze potrzeby - a dokładniej, na potrzeby uczestników dotychczasowych eventów. To Wy prosiliście o:

dłuższe sesje

więcej case studies

dokładne, osadzone w Waszych realiach porady.

Ideą POUG Worskhop jest dostarczenie Wam wiedzy w formie półtoragodzinnych, mocno połączonych ze sobą sesji, które razem tworzą zaawansowany warsztat prowadzony przez najlepszych Oraclowych specjalistów na świecie.

Co się nie zmienia względem klasycznej konferencji POUG?

nieformalna atmosfera

merytoryka zamiast marketingu



Rejestracjarozwiń opis

Developing Clusterware Agentsrozwiń opis
All of us use Oracle Database. Most use ASM. Some even embrace ACFS.
But how about Clusterware core feature – which is by definition "clustering"?

To me Clusterware is unique in the way it hides itself behind other Oracle software. Like it wanted to say to us: "I'm just internal layer, I do not require administration nor maintenance, don't tell anybody that I'm free of charge and can do a lot more than I'm doing now...".

So, let's have a look at this software as at typical cluster technology which can bring High Availability to our applications and environment. To achieve this I'll discuss some important fundamentals and share my experience in writing custom Clusterware Agents (good and bad patterns, traps, debugging and logging, etc.). At the end of session we will write together simplest, yet fully functional Clusterware agent for popular application called Single Instance Oracle Database 19c 😉
Michał Wesołowski
Microsoftrozwiń opis

The Heart of Oracle - how the core RDBMS engine worksrozwiń opis
The Oracle database is big, complex, and highly capable. But how the very core of it works is relatively simple - and yet is not often explained.
I will describe the overall architecture of the database, how data is moved from disc to memory *and back*, what blocks are and why their size & distribution is vital to performance. This will include how user data is spread between the SGA nd the PGA and why. Next I will explain the vital role of redo and how it is the most important part of the database. Then I will cover how Oracle maintains a perfect point-in-time view of data and what a "consistent get" really is.
By the end of the talk you will probably understand how the database works better than many experienced DBAs. This knowledge makes all further talks on Oracle performance and features make much more sense.
During the talk you can ask any questions you want. I might even answer them.
Martin Widlake
Systematic Performance Troubleshooting with (free) 3rd Party Toolsrozwiń opis
The speaker frequently faces more and more hurdles during his daily work as an independent Oracle performance consultant because of direct access to the database is restricted for security reasons or a critical performance problem has to be analyzed very fast/remote - especially the latter is a challenge regarding the usual mail-information-ping-pong.
There are several fee-based and free tool-sets on the market that support the DBA and/or external consultant to easily gather all relevant performance and diagnostic data. This talk is focused on the free tool-sets (e.g. SQLd360, Pathfinder and maybe eDB360) that the speaker uses in his daily work with clients. Several - partly uncommon - performance problems will be analyzed and discussed with help of these tools. Please feel free to bring your own SQLd360 reports with you - so we can analyze them live during the talk :-)
Stefan Koehler

The foundations of understanding Execution Plans.rozwiń opis
One of the key components of good applications is efficient SQL, and if you need to understand why some piece of SQL is not executing efficiently then it's important that you are able to create, share, and interpret truthful execution plans. This presentation will give you a solid understanding of how to meet all three of those targets.

Most presentations on execution plans start with a simple instructions on how to create them and then how to read very simple plans. This presentation will start at the opposite end of the problem by looking at an SQL statement and asking what the optimizer might do with it and only then look at what that means in terms of the possible execution plans. In this way we gain an introduction to query blocks, transformations, and the reason why we only ever need to look at simple execution plans in order to understand what's happening in complex queries.

From this point we look at plans for a single query block; then examine the ways that Oracle presents plans that involve multiple query blocks in several different circumstances. This will lead us to the problems that the optimizer has with working out how to choose between doing a transformation that eliminates a query block, or isolating a query block and having to execute it multiple times at run-time - at the same time we'll discover that there are run-time optimisations (tricks) that Oracle uses that will make the optimizer's calculations (or guesswork) produce totally unrealistic estimates.

From a purely technical viewpoint we will be covering the packages dbms_xplan and dbms_momitor, and the three most important parts of an execution plan - the operation (body) of the plan, the predicate information, the statistics information (estimated and actual) with some passing references to the outline information and the projection information.
Jonathan Lewis
The logwriter 2020: the good, the stats and the uglyrozwiń opis
The way the logwriter works is mostly entirely undocumented, and what is officially documented can put you on your wrong foot. The purpose of this talk is to highlight the way the logwriter works, and more importantly what you can see and measure for yourself using common database statistics.

This talk looks at the relevant internal/c functions executed by the logwriter, and provides the sequence in which they are executed and statistics they produce. This should allow database tuners to understand what the impact of logwriter performance is, and in what part time is spend.

Another topic is the difference in how the database is working by choices like RAC and multi-tenant.
Frits Hoogland

Przerwa obiadowarozwiń opis

Wait Events and DB timerozwiń opis
Your first sight on your database performance is probably from the Enterprise Manager "Top Activity" or equivalent: the load of the database on the time axis, displayed with colors. Green for CPU, blue for I/O, red for locks... Behind those colors are the wait events which you can also query from many monitoring places: V$ views, Statspack report, SQL Trace. They tell a lot about what the database is doing or waiting on, as long as we understand exactly what they measure. We will get through the most common ones to understand what they tell us, and how we can improve the performance.
Franck Pachot
10053 + CBO transformation/statsrozwiń opis
Lets talk abut the Oracle 10053 trace and how it explains what decision Oracle is making when optimizing your SQL. We will see how Oracle uses your statistics to make judgements about which optimization path to take and how it short-cuts the process to minimise optimization time and get to a reasonable plan as quickly as possible.
Neil Chandler

Beginners' Guide to using the AWRrozwiń opis
In this session we will draw pull together the strands from the three previous sessions as we get to grips with the information that's available in the Automatica Workload Repository (AWR) or (for those without the diagnostic and performance licences, or running Standard Edition) the free Statspack utility.

If a user can tell you exactly where they are having a problem - which report is taking too long to run, which screen is responding very slowly, which drop-down menu is oozing like honey instead of dropping like a stone - then there are high precision strategies you can use to identify the cause of the problem. The AWR is there to help on those occasions when the database appears to be generally "unhealthy", or pushing the limits of the hardware, or showing random variations in performance.

The three previous sessions of the stream will have examined:

* How the core RDBMS engine works
* Wait Events and DB time
* Execution Plans

In this session we learn how the AWR can help us build a picture of what the engine is doing and give us some clues about how we can reduce the core activity cut back on basic resource consumption; we learn to recognise the relationships between the wait events and instance activity stats that tell us why the database is working harder than we expect; and we find easy ways to track down expensive activity and understand why the underlying execution plans may need to be address.

The bottom line on using the AWR is that it allows you to find the worst examples of excessive resource usage caused by one of two key problems

* You're doing something the hard way
* You're doing something too often

The numbers will tell you how to reduce the workload - but you still have to remember that that might not make any visible (response time) difference to the end user
Jonathan Lewis
Full Stack Tracerozwiń opis
Your report runs slow? DATABASE FAULT! Transaction performance is low?
DATABASE FAULT! Application down again? DATABASE FAULT! And what
about the rain? Wait, but what if not… ?
After migrating the test database to Oracle Exadata Cloud at Customer, the customer
wanted to send us to the cloud… The performance was awful. Really - like 7
times slower. But funny story - not from AWR perspective. From AWR
perspective everything was pitchy. Almost every SQL was faster.
In this presentation we will show the full stack trace to discover performance problems. From SQL*Net using STADO to AWR using AWR_ANALYZER. From strace to perf. From one beer to another.
Kamil Stawiarski
Radosław Kut

Zakończenie konferencjirozwiń opis




Jak dojechać

Hotel Indigo Warsaw

Smolna 40, 00-375 Warszawa
Strona www

After party

Zostań sponsorem

POUG to nie tylko oficjalna społeczność Oracle – to przede wszystkim baza bardzo aktywnych użytkowników, angażujących się w rozwój grupy zarówno podczas samych spotkań, jak i w trakcie przygotowań do nich. Nasz przekaz dociera do blisko 400 osób związanych z bazami danych – od administratorów po deweloperów, od początkujących po ekspertów z wieloletnim doświadczeniem.

Zapraszamy Państwa do współpracy przy organizacji kolejnego spotkania POUG. Bycie partnerem biznesowym daje Państwu możliwość zaprezentowania swojej marki przed i podczas wydarzenia.


Tak, zgadzam się na przetwarzanie moich danych osobowych w celu realizacji kontaktu handlowego związanego z treścią przesłanego poprzez formularz zapytania na wskazany przeze mnie adres e-mail. Zostałem/am poinformowany/na, że zgoda może zostać cofnięta w dowolnym momencie. Potwierdzam też, że zapoznałem się z zasadami przetwarzania moich danych określonymi w Polityce Prywatności LINK. Administratorem danych osobowych jest „Database Whisperers sp. Z o.o. sp.k.” z siedzibą pod adresem Al. Jerozolimskie 200, 02-486 Warszawa, e-mail: info@ora-600.pl. Więcej informacji w Polityce Prywatności LINK.