This is a short note to point out that I just added to the Public Appearances page the next conference organized by the AOUG in Vienna. It will take place on June 15. My talk will be about edition-based redefinition. The full agenda (incl. abstracts) is available here. It is interesting to point out that the two key-note speakers are Tom DeMarco and Tom Kyte.
The terrific agenda of the first Michigan OakTable Symposium is online.
I plan to give the following presentations:
- Edition-Based Redefinition
- Interpreting Execution Plans
- Transaction Management Internals
The abstracts are available on my Public Appearances page as well as on the event’s site. By the way, the early bird registration ends April 30.
An execution plan describes the operations carried out by the SQL engine to execute a SQL statement. Every time you have to analyze a performance problem related to a SQL statement, or simply question the decisions taken by the query optimizer, you must know the execution plan. Whenever you deal with an execution plan, you carry out three basic actions: you obtain it, you interpret it, and you judge its efficiency.
I have always found it surprising how little documentation there is about how to interpret execution plans, especially since there seem to be so many people who are unable to correctly read them. I addressed this problem not only in Chapter 6 of my book, Troubleshooting Oracle Performance, but also by presenting this very same topic at several conferences and user-group meeting (e.g. UKOUG, Orcan and SIOUG). The last time I presented it, it was few days ago at Oracle OpenWorld in San Francisco. By the way, big thanks to everyone who attended my presentation! It was really good to see a packed room. That said, I’m truly sorry that Oracle has not been able to provide us with a decent room. I was embarrassed for them…
The aim of this short post is to point out that I just uploaded the slides that I presented at different events here. Since the slides themselves contain few explanations and, therefore, are not very useful without additional information, I also added comments whenever necessary (e.g. where there is an execution plan). I hope you find that document useful.
The company I work for, Trivadis, organizes a series of 1-day seminars covering the most important features of Oracle Database 11g Release 2. The following dates and locations are currently planed (some more might be added later on):
- 2009-12-10 Zurich (CH)
- 2010-01-19 Frankfurt (DE)
- 2010-01-20 Munich (DE)
- 2010-02-02 Stuttgart (DE)
- 2010-02-04 Vienna (AT)
My involvement with these seminars is twofold. First, along with several colleagues of mine I’m currently testing the new features and writing slides not only about how they (should) work, but also about the problems we experience during our tests. Second, I’ll be presenting, along with another colleague (every seminar has two speakers), at the seminars in Zurich, Frankfurt and Munich.
Addition information is available here.
In the next months I’ll be speaking at several conferences and user group meetings. I’m looking forward to meet some of you at one of these events.
The abstracts of the presentations are the following (in Switzerland and Germany I’ll give the presentation in German; hence the last abstract is in German. The short summary is that I’ll present the Oracle Database 11g Release 2 feature called “Edition-Based Redefinition”):
- Interpreting Execution Plans: An execution plan describes the operations carried out by the SQL engine to execute an SQL statement. Every time you have to analyze a performance problem related to an SQL statement or simply question the decisions taken by the query optimizer, you must know the execution plan. Whenever you deal with an execution plan, you carry out three basic actions: you obtain it, you interpret it, and you judge its efficiency. The aim of this session is to describe in detail how you should perform the second of these three actions—in other words, how to read execution plans.
- Parallel Processing: When you submit a SQL statement to a database engine, by default it is executed serially by a single server process. Therefore, even if the server running the database engine has several CPUs, your SQL statement runs on a single CPU. This means that the amount of resources used for the execution of a SQL statement is restricted by the amount of processing a single CPU can do. The purpose of parallel processing is to distribute the execution of a single SQL statement over several CPUs.
This session describes not only how parallel processing works, but also when to use it. In other words, how it can be used to improve performance. In addition, it also describes how to configure the database engine to efficiently support it.
- Edition-Based Redefinition: Das Upgraden von kritischen Applikationen kann sehr schwierig sein. Eines der Hauptprobleme besteht darin, dass aus Verfügbarkeitsgründen regelmässige und lange Downtimes nicht eingeplant werden können. Deshalb ist es wünschenswert online Verfahren für solche Upgrades zu implementieren. Dies bedingt nicht nur eine Applikation die dafür vorgesehen ist, sondern auch dass jede benutzte Software, wie z.B. der Datenbank Server, online Upgrades zulässt. Oracle hat dieses Problem seit Jahren erkannt. Leider wurde dies bis und mit Database 11g Release 1 nicht umgesetzt. Ab Oracle Database 11g Release 2 hat sich diese Situation sehr stark geändert. Mit „Edition-Based Redefinition“ bietet Oracle eine echte Unterstützung um online Upgrades zu implementieren. In diesem Vortrag wird diese neue Funktionalität im Detail präsentiert.