I am quite excited to have been accepted to speak at the upcoming DOAG Exaday taking place June 20 in Frankfurt. It is the third time I have been lucky enough to present at the event, having spoken both in Frankfurt in Hamburg in previous years.
As you can probably imagine by looking at this weblog, I am a great supporter of the Oracle Engineered Systems community. My interest is not limited to Germany: I still remember the many great meetings in London in the context of UKOUG’s Exadays. I am also very lucky to work for @enkitec where we have been sharing real-world experience at E4 for years and will do so again in June this year.
As developers, sometimes we set something running that we wish we hadn’t And naturally, we’d like to be good IT citizens and clean up the mess as quick as we can. (For most of us, this means – cover our tracks before the phone rings about smoke coming out of the server). But of course, getting an administrator to hand over the trigger to let you have the ALTER SYSTEM KILL SESSION command is probably unlikely because…well… it’s just a bad bad idea. So here’s a wrapper which might serve as a starting point for you. It expose the kill system command to you, but in a restricted set of circumstances.
By default, we report any session that has a status of active or killed. We’ll see the session details, whether it’s running or blocked, plus the SQL ID etc.
I did a little demo of sharing a tablespace between two databases a few days back – you can see the details here or by just scrolling down if you’re on the home page.
To avoid clouding the demonstration I omitted something in the details, but I’ll share that now, because it could be critical depending on how you currently use transportable tablespaces.
Let me do the most basic of examples now, transporting a tablespace from one database to another:
First, we make our tablespace read only, and Datapump export out the metadata
I was reading an interesting discussion today about multiple databases each containing large amounts of read-only data. If that read-only data is common, then it would make sense to have a single copy of that data and have both databases share it.
Well, as long as you can isolate that data into its own tablespace, then you can do that easily with Oracle by transporting the metadata between two databases and leaving the files in place.
Here’s an example
There is a good chance that (based on this blog post title) that you’re expecting a post on SQL, and that’s understandable. But I’ll come clean nice and early – that was just to lure you in
The post is about SUM and DISTINCT, but not in the technical sense.
Oracle Scene, the magazine of the UK Oracle User Group is piloting a new regular feature called Ask Jonathan, a chance to get an answer to any question you may have about how the Oracle database engine works.
I’m aiming to answer two or three questions per issue over the course of the year, using a format similar to the one Tom Kyte used in Oracle Magazine: so if you have a question about the mechanisms, strategies, or mathematics of how Oracle does its thing then attach it as a comment to this posting.
Ideally the questions will have to be quite short (no 20MB trace files, massive schema definitions, or convoluted and exotic setup requirements or it will be too long), and I’ll aim to write something like half a page of in response. I may summarise the question, or pick out the most interesting feature if it’s a bit too long to publish and answer in its entirety.
I love the interactive grid in Application Express. And here’s why… (Warning: Ranting mode is now on )
You can tell people
If you are running Application Express, there is a new patch available. Lots of fixes which you can read about here
I just downloaded patch 25341386 and followed the installation instructions and it went through with no problems at all in just a few minutes.
Four years ago I wrote about a little volunteer project that my partner did. A small association that provided outdoor experiences and facilities for kids with physical impairments needed a system to record member and volunteer details, plus a few other bits and pieces. We built an Apex solution running on XE. This week, they became part of a larger government initiative, and thus their Apex application was no longer needed and the information migrated to a centralised service. There was a tinge of sadness about that, but I also was pleased with the outcomes of this “project” namely:
While at Delphix, we did a lot of storage benchmarking. The I/O response times of Delphix depends, as one would logically imagine, heavily on the underlying disks. Sure Delphix can cache a lot ( with 1 TB of ram and 3x compression that’s 3TB and that 3TB can be shared by 10 or a 100 copies being the equivalent to 30TB or 300TB of databases) but really there will always be important I/O coming from the storage subsystem.
Now Delphix mainly runs databases loads, so the best test for storage that is hooked up to Delphix is to benchmark the storage I/O for a database workload. Two questions arise