With much enthusiasm I started day 2 of the UKOUG Tech 2014.
At 9:00 I entered room 4B, only to find out, the sessions started a half hour later than yesterday. This gave me some time to blog and half an hour later I attended room 4B again for:
Engaging with Complexity, DTrace for Beginners – Phil Harman
Before, I heard magical things about DTrace: that you can investigate what (Linux, Solaris, MacOS, FreeBSD) processes are doing without influencing performance (very much). So I really wanted to follow a session about DTrace. Phil Harman had 2 hours to fill us in and took his sweet time. But I didn’t mind that much. The first hour was more about philosophy and geekiness. At a certain point Phil mentioned Dr. House MD’s quote “Everybody lies”. I always used that quote in my performance trainings. What Phil/I meant was that, about performance issues, people are usually not lying, but at least misinformed. Another way of saying is “always check your assumptions (and those of others. Especially those of others).
He talked about truss and strace (both rather heavy weight tools), why ZFS sucks (it “breathes”) and about the background info about DTrace. Of course by then, people who went to other sessions in the first hour, could slip into the room and we hadn’t seen any DTrace by then.
But we did get to see DTrace in the second hour. And from what I learned, it really is a cool tool. Not sure yet if it’s “The One True Tool”, but it looks really good. If I might summarize (possibly badly): DTrace allows you to build your own performance tools that are better (or at least better suit your needs) than tools like iostat, vmstat and such. Phil demonstrated a little DTrace code that showed specific I/O stats every 0,1 seconds. And with a file system ready, he really could show how ZFS first does only read, while writing nothing, and later on it would write away a load of data. And I know just the place where I would like to try that code.
Securing, Review and Lockdown Oracle – Pete Finnigan
Of course I had to see what Pete Finnigan was up to. He showed what his security tool called PFSC can do. It gives you a lot of information about privileges, patches and security settings in the database. Pete stressed that security project shouldn’t just be about the database however: it’s about the data.
His view of approaching security projects is: first define what a secure database looks like. Then take the top 10 or 20 most important issues (not the most easily solvable) and solve them.
It immediately made me thing about “agile”. I’ll write about that later.
Zero Downtime Migration Using Logical Replication – Chris Lawless
To be honest, when I saw Chris’ presentation template from DBvisit, I feared I had entered a product presentation. But luckily this was not the case. This session was a high over overview of methods of zero downtime migration. This is possible with Oracle Gateway, Oracle Streams, and also DBvisit’s product, but that was not the point.
The point was what to look out for with logical replication with any migration tool. Sequences are one possible risk. Because when you insert data in the source database the sequence is updated, what is going to happen at the target database? One way of solving this, is making sequences on the source uneven, the sequences on the target even.
Triggers are also a possible cause of issues. But why let triggers go off on the target, when they have gone off on the source already? Things to avoid as much as possible on the source are DDL and heavy batch jobs. Don’t forget that jobs that delete a lot of data without where clause will be translated into row-by-row operations on the target database.
There were four interesting sessions I wanted to attend at 15:00. But in the end I chose to be the Security Roundtable with Pete Finnigan and about ten people. Some of whom I knew and some I didn’t yet know.
I started basically about my idea of attacking security projects with Agile. I’m going to write a blog post about this soon. The idea is that you have a list of security issues to solve, in order of importance to the company/organization. And then you decide in sprints of 4 weeks what you are going to solve. A sprint of four weeks (or several) is something your employer probably can decide relatively easy on whether to go ahead or not. The outcome of a sprint is not always clear, of course. You can encounter unforeseen issues, dependencies, etc.. But this is no different than when you decide to do a project of 8 months.
We also talked about how you can get managers, or whole organizations see the importance of security. I brought up my password cake example. Security awareness is important. Scaring them might work (I remembered my presentation with the fake cover story on a newspaper (“<Your organization> hacked. Russian hackers demand millions of <currency>.” that I did once). Influencing decision makers on security issues is an important topic. I start to see this more and more as a sales/marketing problem. I have to read “Influence” by Robert Cialdini again for this.
We also talked about storing passwords (in encrypted password tools like Password Safe and Keepass).
Emergency Migration to Exadata – Andy Colvin
Beforehand I thought how anyone could have to do an emergency migration to Exadata, but Andy’s session made that quite clear. His tale was one of horrors at a customer that should not be named (and wasn’t of course). His tale was also one of lots of downtime and incompetency on many layers. (For some reason the DBA used to leave the country every time downtime was planned.)
The reason why an emergency migration was necessary, was because on the AIX system was basically not savable at one point. With many jobs on the line, at long last, the decision was made to migrate to Exadata.
Things I picked up along the way: 8K is the default block size in Exadata and only when you can come up with very sound reasons, you deviate from that. I also liked the retention time they chose in their new system: 13 months (not days, Rabobank, months!). Because, why the heck not? It doesn’t take up that much space anyway.
Big Data in Exadata – Chris Kutrovsky
This session was actually a follow-up on a session that went before about SQL vs. NoSQL. Chris first described how much data Exadata actually can work through and in what time. Something like 2,5 GB per second (forgot in what config).
He then discussed how parallel query can go through that data efficiently. The effectivity of these operations where checked in v$pq_tqstat. The interesting thing was that parallel queries with an order by on Exadata have a problem with a Ranger bug. That is: the parallel slaves don’t divide the work very efficiently. And the resulting problem is called “the convoy effect” (other processes are waiting for the one that has to do the most work.)
When doing Big Data operations in Exadata, partitions are “almost mandatory”, according to Chris after considerable experiments.
And with that it was time for the Tech14 Social. We got a nice meal and I spoke with a couple of interesting people. And my takeaway was: I really need to be more on conferences like this and to achieve that, I’ll need to do presentations at conferences again.