Some time ago I wrote this post.
The Problem With Oracle : If a developer/user can’t do it, it doesn’t exist.
As a result of that post I was invited to speak to a bunch of product managers at Oracle. In that session I spoke about the contents of that post and also about my thoughts regarding a layered approach to product design. I thought I would briefly outline the latter here.
Here’s a list of reasons why SELECT * is bad for SQL performance, assuming that your application doesn’t actually need all the columns. When I write production code, I explicitly specify the columns of interest in the select-list (projection), not only for performance reasons, but also for application reliability reasons. For example, will your application’s data processing code suddenly break when a new column has been added or the column order has changed in a table?
Here’s a list of reasons why SELECT * is bad for SQL performance, assuming that your application doesn’t actually need all the columns. When I write production code, I explicitly specify the columns of interest in the select-list (projection), not only for performance reasons, but also for application reliability reasons. For example, will your application’s data processing code suddenly break when a new column has been added or the column order has changed in a table?
I have written previously about partitioning the PS_LEDGER table in Financials for the benefit of General Ledger (GL) reporting. I have always recommended top-level range partitioning on the combination of FISCAL_YEAR and ACCOUNTING_PERIOD with separate partitions for each accounting period. It also leaves sub-partitioning available to use another column, usually LEDGER.
However, recent research into partition change tracking (PCT) and materialized views has made me question that advice. The decision is not as clear cut.
Here is another example of what I’m sure will just become a plethora of such examples from the community on how the flexibility of SQL macros can solve problems that would normally take a lot of code in the form of DBMS_SQL and/or object types and/or pipelined functions and/or …well, you get the idea
In today’s video we’ll discuss the Adaptive Cursor Sharing feature, introduced in Oracle 11g Release 1.
This video is based on the following article.
Here are some other things you might want to check out.
After much badgering from a number of you (you know who you all are), I’m pleased to finally announce the scheduling of 2 new webinars for February 2021 !! As usual, places are very strictly limited as I only run small classes to give every attendee the opportunity to get the most from the […]
In this post I will show you how to break down Linux system load by the load contributor or reason. You can drill down into the “linux system load in thousands” and “high system load, but low CPU utilization” problem patterns too.
Introduction - terminology Troubleshooting high system load on Linux Drilling down deeper - WCHAN Drilling down deeper - kernel stack How to troubleshoot past problems Summary Further reading Introduction - Terminology The system load metric aims to represent the system “resource demand” as just a single number.
Recent comments
3 years 3 days ago
3 years 12 weeks ago
3 years 17 weeks ago
3 years 17 weeks ago
3 years 22 weeks ago
3 years 43 weeks ago
4 years 11 weeks ago
4 years 41 weeks ago
5 years 25 weeks ago
5 years 26 weeks ago