Huh? Is It Fixed in 23c? Seriously!

No matter how long you’ve worked with Oracle Database, you’ll benefit from hearing our database upgrade team’s insider insights. Follow as we describe how a service request becomes a patch. Learn about the time it takes to deliver a patch, what the requirements are to include a fix in a future release update (RU), and why certain patches may never be in a Release Update for your current database release. When do you need a merge patch? And why is Windows different? And where can you find all this information? Find out all this and more.

Percentiles, lies, and database performance monitoring

It is becoming increasingly popular these days to put response time percentiles into the SLAs and OLAs. But, unfortunately, most people do it wrong. In this presentation, we will explain the most common failure modes regarding performance metrics and how to handle situations when someone comes complaining with a 99th percentile graph.

Response times are often not normally distributed, and averages and dispersions are just garbage. The simplest way to make sense of such data is to use percentiles. Popular choices are 50th (median) and 99th percentiles. By definition, there can be values larger than 99th percentile, so adding 99th percentile to the SLA will hide outliers.

Oracle provides histograms for the wait events, for query response times it is still only averages. The only way to get a hold of the outliers is ASH or event 10046 traces. As always, these options come with their own challenges.

What the Heck is the Oracle Optimizer Doing? Part 2 - Plan Costing

When Oracle optimizes your SQL, it works out what it thinks is the best way to execute your statement to retrieve your data as quickly as possible, minimising unnecessary resource usage. This presentation will look at what Oracle is doing. We will use the 10053 trace functionality to show how Oracle uses statistics to cost your SQL access paths, showing what cost really means and how it works, and the impact of messing with system statistics on your database.

Stop editing code in Production database - a journey from 90's to CICD

Source control in databases is a difficult problem. There are tools like Liquibase or Flyway but none of those is fully addressing all challenges of applying changes to databases. This presentation is based on real life implementation and shows a story of a company moving from direct PL/SQL code edit on production server to CICD pipeline.

List of the typical challenges covered in the presentation: - how to design a source control repository, - how to keep a DDL changes, - code merges, - continuous deployment without production outages - rollback - pipeline implementations

Presentation will finish with lesson learned and potential process and tools improvements including Oracle Cloud DevOps tools.

What the Heck is the Oracle Optimizer Doing? Transformations

When Oracle optimizes your SQL, it works out what it thinks is the best way to execute your statement to retrieve your data as quickly as possible, minimising unnecessary resource usage. This presentation will look at what Oracle is doing. We will use the 10053 trace functionality to show how Oracle is transforming your queries, perhaps in ways you didn't think it was doing!

Huh? Is It Fixed in 23c? Seriously!

No matter how long you’ve worked with Oracle Database, you’ll benefit from hearing our database upgrade team’s insider insights. Follow as we describe how a service request becomes a patch. Learn about the time it takes to deliver a patch, what the requirements are to include a fix in a future release update (RU), and why certain patches may never be in a Release Update for your current database release. When do you need a merge patch? And why is Windows different? And where can you find all this information? Find out all this and more.

Migrating a TB Database from 11g Windows to 19c Linux in less than an hour

Upgrading a database with plattform migration is always challenging especially if you should hav a very short downtime. There are many ways to do this. In a recent project I used Transportable Tablespace for that. I'll show how I did this and what could go wrong.

Kako ukrotiti pobegle SQL stavke po nadgradnji baze, aplikacije ali hardvera?

Po nadgradnjah baze, aplikacije, hardvera in tudi po instalaciji patchsetov se rado zgodi, da nekateri SQL stavki pobegnejo - se ne izvajajo več tako kot pred spremembami. Če se izvajajo hitreje, to nikogar ne boli. Problem pa nastane, ko se začnejo izvajati počasneje.

Kakšne možnosti imamo, da izvajanje teh stavke "fiksiramo"? Kako to dosežemo tudi v Standard ediciji baze?

Ogledali si bomo tudi način, kako take stavke najti.

==============

After upgrading databases, applications, HW or even after installing patch-sets it often happens that some SQL statements go wild, meaning they start performing significantly different compared to their behavior before the change. If performance is better then no one will complain, but if it is worse then you might have a problem.

What options exist to confine the execution of such statements? How this can be done in DB Standard Edition environments?

You will also find out how such SQL statements can be located.