Monika Lewandowska
Autonomous
Actions
Monika is an experienced Oracle architect, designer, and developer. She has started her journey with Oracle in the last century with Oracle DB 7, continues to this day. She emphasizes the solution's simplicity, code quality, best practices, and above all - system performance.
She is an Oracle Ace and willingly shares her experience.
She loves fast motorcycles and databases!
The Blair Witch (DB) Project
What do Freddy Krueger, Chucky, and bad DB design have in common?
They all can keep you up at night!
Designing is one of the most crucial stages of the software development process and a good DB architecture is one of the keys to good quality systems.
Unfortunately, bad decisions made at the database design stage can have a very negative impact on the performance and management of the system and in extreme cases, it’s a real horror to handle.
These errors are enormously costly – fixing is very time-consuming and often requires refactoring and redesigning a large part of the system. The good news is that with some planning and thinking, these real horror cases can be avoided and a good design can be a solid base for our software.
In the session, we will investigate some of these extreme cases and their impact on the system, and hopefully, just like most horror movies, we’ll manage to beat the monsters.
The Big :Bind Theory: Bind Smarter, Run Faster
When it comes to database performance, few topics are as fundamental — and as misunderstood — as literals and bind variables.
We've been taught that bind variables are our friends, helping avoid hard parses and boosting efficiency. But is it really that simple? Or, like in the famous double-slit experiment, does the mere "observation" — the values we pass — change the behavior of our queries?
• How bind variables influence PARENT and CHILD cursors
• When cursor sharing helps — and when it backfires
• How :BINDS affect cardinality, selectivity, and execution plans
• Whether cursors can adapt to different bind values (Adaptive Cursor Sharing)
By the end, you'll see that bind variables — like quantum particles — don't always behave the way we expect.
The Big :Bind Theory: Bind Smarter, Run Faster
When it comes to database performance, few topics are as fundamental — and as misunderstood — as literals and bind variables.
We've been taught that bind variables are our friends, helping avoid hard parses and boosting efficiency. But is it really that simple? Or, like in the famous double-slit experiment, does the mere "observation" — the values we pass — change the behavior of our queries?
• How bind variables influence PARENT and CHILD cursors
• When cursor sharing helps — and when it backfires
• How :BINDS affect cardinality, selectivity, and execution plans
• Whether cursors can adapt to different bind values (Adaptive Cursor Sharing)
By the end, you'll see that bind variables — like quantum particles — don't always behave the way we expect.
SQL: Good and evil are the same thing.
SQL is one of the most powerful languages. It gives us direct access to a database and allows us to manage the data: query, change, or delete it. We can join multiple tables, perform complicated calculations, and much more! That makes the possibility to use SQL directly from PL/SQL code one of the best features of Oracle.
But, as Heraclitus said, Good and evil are the same thing - this possibility is one of the biggest problems in Oracle, too. Mixing SQL and PL/SQL code is so easy and tempting, that we do it all the time without giving it a lot of thought. The consequences, however, are serious and impact the clarity of the code, its testability, and the overall system performance.
In this talk, I will show that although SQL is a very powerful tool, it is not healthy for your system to have too much of it. I will show how you can get rid of some unnecessary SQL and therefore keep the good while avoiding the evil that comes with it.
Join me and see how to organize your database code to maximize the benefits of the powerful SQL and PL/SQL capabilities and avoid its hidden danger.
Live coding and examples on demo!
Performance Grand Prix – Who Will Win the Race?
Every day, we race for better performance – optimizing SQL queries, searching for tricks and methods to retrieve and modify data in the most efficient way possible.
But have you ever wondered why some techniques are faster? Are they always better? And – most importantly – how much can you really gain from using them? Join us for the exceptional Performance Grand Prix, where various SQL techniques will compete for the title of efficiency champion!
At the starting line, you'll find a mix of classic and refined approaches. Your task? Guess which one will cross the finish line first. Participate in interactive quizzes, place your bets on the winner, and discover whether your chosen technique earned the trophy. Will an index scan outpace a full table scan? Or will an underdog surprise everyone?
Don’t miss this chance – hop into the driver’s seat and join the race for knowledge and performance!
Oracle The Most Mysterious Cases
It was on a cold day in November when the silence was broken by a desperate scream: ‘Kill it! Kill it!”. The boss immediately pushed the button and brutally terminated the session. It has happened again… The Performance was murdered. Boss flicked through the case files. There were no usual suspects. Where is the murderer hiding then?
The desk was buried under the cases’ files similar to this one. The File that hasn’t been seen in production for 6 months, the whole team has been looking for it, but there was no progress, not even a clue…
Another reported missing - Data has left the Source System but never reached the Destination server…Nobody has seen it again…
This is too much for one person. And that’s why I need YOUR help!
During the session, we will solve all the mysterious cases together and we will find out what is responsible for the strange behavior of the system. Is the source of the problem a huge design error or a small decision at one of the stages of development? How minor design decisions can affect the system's performance and vulnerability to errors? Who is the murderer?
The answer may surprise you!
How to do Unit Tests and Not go Crazy (and Bankrupt)
Unit tests are useful. Unit tests are essential. All of us are doing the UT, aren’t we? We try to do our best but in real life, UTs are expensive and consume a lot of time. When we finally find a bug - it turns out that the bug is in the test itself.
And the deadline is coming…
Can we do the UT easier, less expensive, and more effective?
YES, WE CAN!
I would like to show you how to design your application, write your PL/SQL code and prepare test cases in a way that will help to build Unit Tests and perform them in a fast, efficient, and exciting way!
Backoffice system re-engineering- key success factors - case study.
During the night, Back-office systems have to process tons of records and calculate millions of values. Systems usually are very busy during the night. But is the night long enough to do such hard work? The end-of-day processes in the back-office systems can take several hours. Record holders are approaching even 24 hours!
In the session, I will discuss a successful system re-engineering project that involved gathering information on the current system and analyzing requirements, and transforming them into the system of tomorrow. I will walk through the main process I went through: the requirements, design, PL/SQL code, and the changes that allowed us to shorten the processing time. Not only did we improve a single process but the entire system processing time was reduced from several hours to several minutes.
Come to this session and find out what were the key factors to achieving success!
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top