POUG Workshop - a new format of Polish Oracle User Group Conference

03.07.2020, Warsaw

POUG (Polish Oracle User Group) is a community that was set in 2016 by Database Whisperers sp. z o.o. After dozens of great meet-ups and four 2-days-long international conferences, we decided to introduce you new format - POUG Workshop.

We know it might sound cheesy but the truth is YOU were the inspiration for the new idea. It was you who asked us for:

  • longer sessions
  • more case studies
  • precise examples

Our goal is to provide you maximum knowledge in a form of 1,5-hours-long and connected to each other sessions which all together create advanced workshop (run by THE BEST Oracle experts from all over the world).
We offer you something new, but some things will never change. For example:

  • easy-going atmosphere
  • knowledge instead of marketing
  • beer:)


Registrationrozwiń 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

After party

POUG Partnership

POUG is not only the official Oracle community – first of all it is the base of very active members, who are engaged in the group development both during the meetings and the preparations to them. Our message gets to the 400 people connected with databases – from the developers to the administrators and from the begginers to the experts with years of experience.

We would like to invite you to be a part of our event – it is a chance to show your brand during and before the meeting. What does it mean?