sorted by: recent | see :
popular
Content Tagged with non-tech + oracle
Log Buffer #116: A Carnival of the Vanities for DBAs
Welcome to the 116th edition of Log Buffer, the weekly review of database blogs.
This was the week of Oracle Open World (OOW), Oracle’s gigantic annual get-together in San Francisco — always the heaviest week in Oracle blogs, so let’s start there.
For day-by-day coverage of OOW on the ground, I recommend Doug’s Oracle Blog: OOW Day 1, OOW Day 1.5, OOW Day 2, OOW Day 3.
Tom Kyte shared a podcast from OOW 2008, and interview with Oracle Magazine editor Tom Haunert, in which Tom, “ . . . stirs things up in this conversation about Oracle OpenWorld happenings, a new approach to publishing, and the trouble with triggers.”
Oracle teased everyone right at the beginning with word that CEO Larry Ellison’s keynote, carrying the title “Extreme Performance,” would introduce something big and new. And there was much speculation in the blogging world, some of it quite perspicacious. “Big and new” was soon going by the tantalizing nom-de-hype “X”. And before Larry’s keynote was even over (before he mothballed the black mock-turtleneck for another year), X was no longer unknown.
Writes Lucas Jellema on the AMIS Technology blog — The secret is out: Oracle launches The Database Machine - becoming a hardware vendor! “The big announcement that had loomed over the conference has been made. Oracle - in joint partnership with HP - introduces the worlds fastest hardware for running databases and especially data warehouses: the Exadata Storage Server.” Click through for Lucas’s précis of what it’s all about.
On blogs.oracle.com, Jack Flynn has some video excerpted from the keynote.
Lucas’s story has a picture of the thing itself, albeit a somewhat blurry one. Here’s a better image of one of the two new machines, the Exadata. Oooh, just look at it! Cor!
Much Oracle Ado
If you track the database world outside of MySQL, you know that Oracle is having a conference this week. It’s called Oracle Open World. Drips with irony doesn’t it? But this post isn’t about Oracle being open or otherwise.
This post is about the announcement being made Wednesday. It seems Oracle has a surprise. A pretty well kept surprise. It’s such a big deal that Larry Ellison himself is making the announcement.
Some people, including some of my colleagues at Pythian, are speculating that this is going to be an announcement about a share-nothing clustering solution.
In the first quarter of 2007, I interviewed with a company in Atlanta, seeking my first full-time job as a MySQL database administrator. They were an online company building a social-networking website with a virtual world interface (kind of like Second Life, from what I understood). They were using an (at the time) fairly unstable version of MySQL 5.1 only because it offered clustering with the ability to store data on disk while keeping the indexes in memory. Previously, in version 5.0, everything had to be stored in-memory. Much has improved with MySQL clustering since that time.
While I don’t know for certain that Larry is going to announce in-memory clustering, I kind of hope that is what it’s all about, because it would demonstrate this: Oracle is walking a trail blazed by MySQL.
Log Buffer #115: A Carnival of the Vanities for DBAs
Welcome to the 115th edition of Log Buffer, the weekly review of database blogs.
I must thank Paul for taking over at last minute for LB#114 last week, when, as he put it, “ . . . a killer combo of painkillers and the pain that the painkillers cant kill . . . ” reduced to me a less-than Log-Buffer-capable state. Or to be more precise, to a writhing, benighted gargoyle of misery. (Too colorful?)
Anyway, the good news is that I’m better. Not all better, mind you. Between the tooth thing and my spending all my working time on a special project, there was nothing left for poor old Log Buffer. So, I face the choice: throw it open to you, LB’s loyal readers for your contributions; or adopt Paul’s approach1 from last week, and use the nifty AideRSS.
I’m going to bet on our readers. Let’s hear from you with your picks for best database blogs of the week gone by. I promise you a real, proper Log Buffer next week, from someone. If not me, well, Nick Westerlund still wants his go, and Ward Pond is back looking for a slot.
Until then, wish me luck with my angry tooth.
1. The truth is that I was briefly worried about having my job taken away by software. My concerns were allayed, at least partially, when I saw that the original software-built list of database blogs also included an item from “manscaping.com”, which I’m fairly sure had little or nothing to do with database administration.
Sheeri?s Sordid Past
I confess — I have not always been an exclusive MySQL user. I have fooled around with other DBMSs. I was young, inexperienced, and I needed the money, I swear!
This comes about because I was doing some electronic de-crufting….From a file last modified on 10:50 am on 2005-06-30:
> more addcatalog.sh #!/bin/sh db2 catalog tcpip node $1 remote $2 server 50000 db2 terminate db2 catalog database sample as $2 at node $1 db2 terminate # [db2inst1@midgard db2inst1]$ db2sql92 -a db2inst3/password -d coworkername
And from the same time-frame there’s also:
Log Buffer #112: A Carnival of the Vanities for DBAs
Welcome to the 112th edition of Log Buffer, the weekly review of database blogs.
First, thanks to last issue’s contributors–Joe Izenman, Dan Norris, and Jason Massie–for snatching victory from the jaws of defeat and making LB#111 a worthwhile read. That’s what it’s all about!
Oracle’s up first, starting with our old friend Doug Burns and his Time Matters series, in which he holds up to the light the concept of DB Time: “. . . [the] total time spent by user processes either actively working or actively waiting in a database call.” He continues, “There’s a lot more I could say about DB Time. Like all of the best performance concepts or methods (e.g. YAPP, Method-R) it can seem so obvious as to not be worth saying, but contains an enormous amount of common sense and technical rigour.”
Arup Nanda writes about the time he spent Diagnosing Library Cache Latch Contention. About half an hour, as it happened, but he’s a real pro, and his analysis just goes to show. To quote, Nuno Souto–who makes the best blog endorsements– “Damn useful stuff . . . bookmarked.”
Tanel Poder has another script for you to fall in love with, which makes its debut in flexible sampling of any V$ or X$ view with sample.sql. It is, writes Tanel, “ . . . a simple but powerful sqlplus script for ad-hoc sampling of any V$ view.”
Kenneth Downs, the Database Programmer, offers Advanced Algorithm: Sequencing Dependencies, a smart look at satisfying dependencies in databases. What does that mean? Well for example, Kenneth writes, “All popular Linux distributions have a package installation system in which each package lists its required dependencies. If you want to install a large number of packages in one shot, producing a tangled bunch of related dependencies, today’s algorithm can be used to work them all out.”
That’s the kind of task for which we humans use tools like mind maps. Jason Arneil shares his ASM Mind Map.
Laurent Schneider went off-road and came back something not on the map at all: the difference between rollbac and rollback.
The Architecture Layer
Contemporary software engineering models include many loosely-defined layers. Database developers might help with other layers, but for the most part a database administrator’s domain is the persistence layer.
- Presentation
- Application
- Business Logic
- Persistence (also called Storage)
The Daily WTF has an article on The Mythical Business Layer makes the case for not separating the business layer and the application layer:
A good system (as in, one that’s maintainable by other people) has no choice but to duplicate, triplicate, or even-more-licate business logic. If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL in the database and have some client-side code to validate it was entered as seven digits. If the system allows data entry in other places by other means, that means more duplication of the Account_Number logic is required.
It almost goes without saying that business logic changes frequently and in unpredictable ways. The solution to this problem is not a cleverly coded business layer. Unfortunately, it?s much more boring than that. Accommodating change can only be accomplished through careful analysis and thorough testing.
I will call this merged business/application layer the “functional layer.”
The serious scaling requirements posed by most applications these days call for partitioning, clustering, sharding or some other term for “dividing up the data so it does not become the bottleneck”. Enter the “architecture layer”.
“Wait a minute,” I hear you asking. “Isn’t that just the persistence layer?”
Yes and no. To me, there’s a difference between the storage and the architecture of said storage. The database schema for storing a user profile is a persistence layer issue. Figuring out which database instance to go to is an architecture layer issue.
This is an important distinction for me. Many folks are coding the architecture layer directly into the functional layer. A “save_profile()” API function might call an ORM to deal with the persistence, or it will have MySQL (or other database) connection handling and queries. However, the database will grow, and at some point you will find yourself wanting to split the data [more].
This type of information, like the presentation layer, needs to be separate. Why should the application care whether save_profile(’Sheeri’,'hair color’,'blonde’) accesses database1 or database2? More importantly, why should there be major code changes to the functional layer if the architecture changes? Just like no functionality has changed when you change your website color from blue to red, there is no functionality change when you go from splitting data between 2 database servers to splitting among 3, or 10.
For me, the persistence layer is about how the data is stored. Which, explicitly and for the record, I also believe should be separate from the functional layer — if you store hair color and eye color in one table or 2, the functionality of the application has not changed; all that’s needed is a change in how that data is stored and retrieved.
The architecture layer is all about where the data is stored. Early forms of the architecture layer are configuration files, though most would not call that a “layer”. Database administrators should be able to change the architecture of the database system without requiring mucking about in the application’s functional code.
Thoughts?
group
oracle
engineering
Articles
architecture
posts
non-tech