Connection pooling demystified

One of the frequent complaints developers receive from DBAs is about misconfigured connection pools and insane number of connections applications tend to allocate. This session explains basics about connection pooling, why they are used, and how to configure them for availability and performance.

Modern web applications tend to operate on request-response model, where every request creates a new database connection. One way to limit the number of connections created and amortize connection setup costs is to use connection pooling. This presentation explains the basic mechanics behind connection pools, how to use them, and how to configure them in a way that both developers and DBAs can be happy.

Main themes of the presentation:

* How to use connection pooling for low response times and high throughput
* Challenges for availability that connection pooling presents
* Connection pool as a circuit breaker
* Technologies from Oracle: Universal Connection Pool, database resident connection pooling and connection manager
* Connection pooling and RAC: FCF, FAN and other cool acronyms

Percentiles, lies, and Oracle performance monitoring

Describing the response time through percentiles is becoming increasingly popular. 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.

One billion row challenge and fast in-memory analytics

In January 2024, Gunnar Morling came out with a challenge: what is the fastest way to process one billion rows in Java? Java is great but what if you used columnar data structures and fast in-memory analytics instead?

The One Billion Row Challenge is well suited for columnar in-memory analytics in general, and for Oracle In-Memory in particular. What would be a better reason to talk about the columnar data structures, memory-optimised processing, and Oracle In-Memory? By the end of this presentation, we will have an answer to the question: what is the fastest way to aggregate over one billion rows?

This presentation briefly reviews some of the more popular columnar in-memory analytics data engines and what toolbox your friendly data scientist might use in Python. How do Apache Arrow and Polars compare to the Oracle In-Memory columnar store? We will discuss in-memory processing, SIMD and real-time analytics in the Oracle database, and outside of it.

This is an introductory session about in-memory analytics and Oracle In-Memory. Preferable session duration is 45 minutes.

Active Session History: tips, tricks and pitfalls

Why would you use Active Session History if you already have AWR and ADDM? This session gives an overview of what is ASH and how to use it to monitor the database and detect performance issues. We briefly introduce the ASH architecture and how to access the data gathered by ASH, with stress on things that are not readily available on the OEM ASH analytics page.

As of Oracle 23c, V$ACTIVE_SESSION_HISTORY has 115 columns. We give an overview of what has been exposed through ASH. Which are more exciting areas in ASH? Is there something not yet included in ASH?

ASH gathers samples of the database activity, meaning that database load and SQL response times have to be estimated from the samples. We show how to estimate the number of active sessions correctly. What is the connection between average active sessions and query response time?

When SQL execution takes minutes, arriving at the correct response time isn't a problem. But what do we do if SQL response times are much less than a sampling interval? There's a way to estimate those response times from ASH as well.

This is beginner to intermediate level talk, with some advanced bits around the response time estimation. Preferred duration of the talk is 45 minutes.