I published a note on AllthingsOracle a few days ago discussing the options for dropping a column from an existing table. In a little teaser to a future article I pointed out that dropping columns DOESN’T reclaim space; or rather, probably doesn’t, and even if it did you probably won’t like the way it does it.
I will be writing about “massive deletes” for AllthingsOracle in the near future, but I thought I’d expand on the comment about not reclaiming space straight away. The key point is this – when you drop a column you are probably dropping a small fraction of each row. (Obviously there are some extreme variants on the idea – for example, you might have decided to move a large varchar2() to a separate table with shared primary key).
For those of you that have been wondering why I’ve been so quiet of recent times, it’s because my wife and I took advantage of a trip to England for UKOUG in December to spend nearly 5 weeks touring around Europe (2 weeks of which was spent river cruising from Amsterdam to Budapest with the fabulous APT river cruises, something I can HIGHLY recommend if you want to see Europe!). But while I might have been taking time off, you can bet the Enterprise Manager developers were not, with the result that Enterprise Manager Cloud Control 13c was released just before Christmas! That makes two releases in a row where Enterprise Manager is the first Oracle product to use a new major version number – EM 188.8.131.52 was the first product to use the version number 12, while EM 184.108.40.206 was the first product to use the version number 13!
I’ve continued to play around with Cloud Control 13c and I’m generally getting a nice vibe from it.
One of the things I really hated about Grid Control 10g and 11g was the navigation. It felt like you had to click on 50 links to get to the thing you wanted. When Cloud Control 12c came along and had a main menu it was a massive improvement. Even so, it was still a little annoying as the menu was split, with some bits on the left and some bits on the top-right.
In Cloud Control 13c, these menus have been brought together into the top-right of the screen.
There’s been a lot of work in the area of profiling. One of the things I have recently fallen in love with is Brendan Gregg’s flamegraphs. I work mainly on Linux, which means I use perf for generating stack traces. Luca Canali put a lot of effort in generating extended stack profiling methods, including kernel (only) stack traces and CPU state, reading the wait interface via direct SGA reading and kernel stack traces and getting userspace stack traces using libunwind and ptrace plus kernel stack and CPU state. I was inspired by the last method, but wanted more information, like process CPU state including runqueue time.
Towards the end of last year I used a query with a couple of “constant” subqueries as a focal point for a blog note on reading parallel execution plans. One of the comments on that note raised a question about cardinality estimates and, coincidentally, I received an email about the cost calculations for a similar query a few days later.
Unfortunately there are all sorts of anomalies, special cases, and changes that show up across versions when subqueries come into play – it’s only in recent versions of 11.2, for example, that a very simple example I’ve got of three equivalent statements that produce the same execution plan report the same costs and cardinality. (The queries are: table with IN subquery, table with EXISTS subquery, table joined to “manually unnested” subquery – the three plans take the unnested subquery shape.)
I wrote a post a couple of months ago called
Which version of Oracle Linux should I pick for Oracle server product installations? One of the points I raised was the use of UEK allows you to have all the latest kernel goodies, regardless of being on an older release, like OL6.
I saw a post today about the release of UEK4, so now you have access to all the improvements in the 4.1 mainline Linux kernel, whether you are on are running OL6 or OL7. That just goes to prove the point really.
An important target of trouble-shooting, particularly when addressing performance problems, is to minimise the time and effort you have to spend to get a “good enough” result. A recent question on the OTN database forum struck me as a good demonstration of following this strategy; the problem featured a correlated update that had to access a view 84 times to update a small table; but the view was a complex view (apparently non-mergeable) and the update took several hours to complete even though the view, when instantiated, held only 63 rows.
The OP told us that the query “select * from view” took seven minutes to return those 63 rows, and wanted to know if we could find a nice way to perform the update in (approximately) that seven minutes, rather than using the correlated update approach that seemed to take something in the ballpark of 7 minutes per row updated.
There was a post on Oracle-L asking about Oracle Express Edition (XE) 12c. I started to write a reply, but thought a blog post may be more appropriate.
Oracle XE 12c doesn’t exist yet, but people at OpenWorld 2015 confirmed they “plan” to have one. As always, no promises. So when will it arrive? Typically the XE version is put together based on the the first major patchset of release 2 of a version. So the kind of thing you might expect is,
Things to consider, based on stuff I’ve heard over the last few years.
The Oracle database has all sorts of little details built into it to help it deal with multi-national companies, but since they’re not commonly used you can find all sorts of odd “buggy” bits of behaviour when you start to look closely. I have to put “buggy” in quotes because some of the reported oddities are the inevitable consequences of (for example) how multi-byte character sets have to work; but some of the oddities look as if they simply wouldn’t be there if the programmer writing the relevant bit of code had remembered that they also had to cater for some NLS feature.