Search

Top 60 Oracle Blogs

Recent comments

Database

[Oracle] DB Optimizer Part XI - Query transformation fixes false cardinality estimation with multiple OR predicates (in newer Oracle releases)

Introduction

This is a short blog post about another query transformation (check my first blog post [Oracle] DB Optimizer Part VIII - Looking under the hood of query transformation (done by CBO) with simple real life example first, if you never heard of the term "query transformations"), that fixes a cardinality estimation issue with multiple (OR) predicates that cover the whole data range. I have to admit that this is a special case, but it can happen as observed by my client

Articles on Oracle Database 12c Multitenant Option

From a technology perspective, the Multitenant option is really cool, but it can be rather difficult to get to grips with some aspects of it. Everything is so intertwined and every feature in 12c somehow links back to the Multitentant option. As I’ve been working my way through the features the same pattern keeps repeating.

  • Write an article on a feature X.
  • Put it live.
  • Move on to looking at feature Y.
  • Notice something about feature Y that affects the article I’ve written about feature X.
  • Go back and revise the article on feature X.
  • Rinse and repeat.

This pattern has made me rather reluctant to post anything on the blog about new articles, because although I don’t release articles until I think they are finished, all these Multitenant articles feel very much like a work-in-progress. I fully expect to step back and revise/rewrite all of them as I figure more out about this stuff.

Data Pump Enhancements in Oracle Database 12c

Another one to file under “Not sexy but flippin’ awesome!”

If you are a DBA, you are going to spend a lot of time with Data Pump. All roads seem to lead back to it. :) There are some more headline worthy features, like transportable database, but the two that jumped out at me were actually pretty small, but awesome.

  • “TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y” – Switches table and/or index imports to NOLOGGING for the lifespan of the import operation.
  • “LOGTIME=ALL” – Puts a timestamp in the output message so you can see how long individual operations took.

I wrote up an article about it here.

Cheers

Tim…

OSP #2c: Build a Standard Platform from the Bottom-Up

This is the fourth of twelve articles in a series called Operationally Scalable Practices. The first article gives an introduction and the second article contains a general overview. In short, this series suggests a comprehensive and cogent blueprint to best position organizations and DBAs for growth.

OSP #2c: Build a Standard Platform from the Bottom-Up

This is the fourth of twelve articles in a series called Operationally Scalable Practices. The first article gives an introduction and the second article contains a general overview. In short, this series suggests a comprehensive and cogent blueprint to best position organizations and DBAs for growth.

OSP #2c: Build a Standard Platform from the Bottom-Up

This is the fourth of twelve articles in a series called Operationally Scalable Practices. The first article gives an introduction and the second article contains a general overview. In short, this series suggests a comprehensive and cogent blueprint to best position organizations and DBAs for growth.

OSP #2b: Build a Standard Platform from the Bottom-Up

This is the fourth of twelve articles in a series called Operationally Scalable Practices. The first article gives an introduction and the second article contains a general overview. In short, this series suggests a comprehensive and cogent blueprint to best position organizations and DBAs for growth.

OSP #2b: Build a Standard Platform from the Bottom-Up

This is the fourth of twelve articles in a series called Operationally Scalable Practices. The first article gives an introduction and the second article contains a general overview. In short, this series suggests a comprehensive and cogent blueprint to best position organizations and DBAs for growth.

Exadata: disk level statistics

This is the fourth post on a serie of postings on how to get measurements out of the cell server, which is the storage layer of the Oracle Exadata database machine. Up until now, I have looked at the measurement of the kind of IOs Exadata receives, the latencies of the IOs as as done by the cell server, and the mechanism Exadata uses to overcome overloaded CPUs on the cell layer.

Warning: Problems with 9.2 clients connecting to databases patched to 11.2.0.4…

I mentioned this a couple of days ago on Twitter, but I’ve only just go round to posting here…

I recently had to back out some 11.2.0.4 patches because the patch seems to cause problems with Oracle 9.2 client connections where 11.2.0.3 worked fine. I’m not sure how widespread the problem is. All I can tell you is we had two separate occasions (services) where this happened, so we’ve put a halt on patching to 11.2.0.4 until we can identify and upgrade the old clients.

Why are there 9.2 clients lurking around? In some cases it’s due to certification of legacy apps. In other cases it’s because the service owner has been working on a, “if it ain’t broke, don’t fix it”, basis. I guess now it’s broke, we gotta fix it. :)

If you have legacy client installations lurking around, you might want to tread carefully when testing this patch.

Good luck!