photo by Stuart Williams
My internet provider said my service was degraded due to the large amount of data uploading from my computer. As far as I knew, my computer wasn’t uploading anything but I didn’t know how to prove it.
I decided to try and write a DTrace program to look at it. (I also installed “Little Snitch” which seems pretty cool).
photo by Idaho National Laboratory
The human brain works so well because it calculates outcomes as it takes actions feeding back the current results compared to the expected results which allows immediate corrections if the two are not aligning.
photo by David Blackwell.
The worst enemy of companies today is thinking that they have the best processes that exist, that their IT organizations are using the latest and greatest technology and nothing better exists in the field. This mentality will be the undermining of many companies.
Christo Kutrovsky, from Pythian, gives an awesome talk at Oaktable World 2013 (see http://oaktableworld.com )
It’s no secret that there are some tasks that overwhelm existing database architectures, making projects consistently come in over budget and overdue. This holiday season, on behalf of Database Administrators everywhere, we’d like to ask Santa for:
An end to the constant struggle for more and more disk space for databases and copies
An army of smart elves to run and test backups
Less dependence on physical/virtual administration and storage teams to create working environments for development and QA
With every release of Oracle, more and more power comes to the optimizer. Many of these are new features (such as adaptive cursor sharing, adaptive optimization, dynamic sampling, etc)…but also within the "core" of the optimizer, there are continuing efforts to transform and interrogate SQL’s to try derive a ‘smarter’ query and hence hopefully a smarter plan.
Its always a balancing act…how much can you re-jig a query without running the risk of actually changing what the query does…
Here’s an example of where that balance is slightly wrong in 12c
In my blogpost When the oracle wait interface isn’t enough I showed how a simple asynchronous direct path scan of a table was spending more than 99% of it’s time on CPU, and that perf showed me that 68% (of the total elapsed time) was spent on a spinlock unlock in the linux kernel which was called by io_submit().
This led to some very helpful comments from Tanel Poder. This blogpost is a materialisation of his comments, and tests to show the difference.
First take a look at what I gathered from ‘perf’ in the first article: