Enough Trace

Question:      How many Database Server trace files does it take for Oracle Support to change a light bulb?

Answer:      We need 2 more Database Server trace files to tell you.

Larry Ellison's answer on September 14, 2017:      "we are doing a log inspection, where we are looking at people and the logs we look at unlike anybody else, we are in the applications business, we are in the database business, and we are in the Cloud infrastructure business looking at network logs and operating system logs, and storage hardware logs, we are also looking at database logs, we are looking at people trying to log on to application systems and the passwords they are reducing."

Enough Trace comment:      This change from Larry is a very welcome development. Going back and forth for months, uploading Oracle Database trace files has resulted in wasted time and unresolved problems. Reference checking all other areas or processing, including real, non trace file activity will produce great benefits.

Vicken Khachadourian

If Christopher Columbus happens to be your neighbor and explains to you his plan .... Get on his ship ...Take the voyage.

Vicken Khachadourian: I hope I'm not plagiarizing anyone by saying what I just wrote above.

You can hang around Shakespeare and improve on every sentence that comes out of his mouth. That does not mean you can write Hamlet. Quit looking for value to apply marginal improvements on. Find your own thing.

Vicken Khachadourian: I hope I'm not plagiarizing anyone by saying what I just wrote above.

Exadata and Raw Iron:

Exadata and Raw Iron are just more Oracle ports. In understanding it and to fully leverage it, you have to factor in all the changes Oracle started making to its Database Engine, starting with V7 in 1992. The underlying fact is that in 1989, Oracle ran on over 120 operating systems. The only way that could be achieved was because Oracle wrote its Database Engine code to rely as little as possible on the operating systems. Oracle did its own locking, buffer cache management, space management, dictionary and object management and all other basic database functions were done with as little dependency on the operating system as possible. By the end of 1990's, operating systems became commoditized and Oracle increased its port specific coding to optimize for the few operating systems that were left. Exadata and Raw Iron are just the next chapter in that transition.

This video by Jonathan Lewis does a great job in placing Oracle's Exadata in context (fast forward to 8:30).

Applying patches to the Oracle Database code:

Even though applying Oracle patches is respectable work, the real danger is in facing what will break in production in the days and weeks after the patch is applied. That is the real challenge. As an Oracle Support rep, a considerable subset of my workload existed because the customer had applied a patch or had done an upgrade, and all of a sudden, things that worked for years without any trouble, broke in very painful ways. The remedy is for all DBA's to understand how their operations are stressing the Oracle Database Engine code, and make the best guess on how the patch is gonna alter the status quo.

This video with Oracle's CEO Mark Hurd lends credibility to the headache customers face in applying patches.

30 year trend to watch:

In the past 30 years, except for 3 areas, all other areas of computing became very inexpensive. CPU power, network access, memory, disk space, programming and all other areas of computing are cheaper today than 30 years ago, but there are 3 areas where computing is exponentially expensive: