Archive
A Brief History of Exadata Time by Juan Loaiza
The full article is available in the 106th issue of the NoCOUG Journal.
“we leveraged our 20–30 years of database experience to determine what would be the ideal platform for running the Oracle database. That’s the thinking that produced the Exadata platform as we know it today.”
“Exadata V1 used HP hardware. Exadata V2 used Sun hardware. Oracle has always worked very closely with Sun, but of course, with Sun becoming a part of Oracle, our relationship became much closer. And, we had a very clear directive from Larry Ellison that engineered systems were critical to Oracle’s overall strategy, and that was understood by both the database and hardware teams. We quickly got all the cooperation, all the features, all the fixes, and all the improvements that we wanted from Sun. When you are a single company and the direction is set very clearly by the leadership, then the hardware and the software integration can advance much faster. If you are two different companies, there are always different priorities in the different companies and this slows down progress.”
When you are a single company and the direction is set very clearly by the leadership, then the hardware and the software integration can advance much faster. If you are two different companies, there are always different priorities in the different companies and this slows down progress.
“When Exadata V1 first launched, it was a purely disk-based system. We added Flash in V2, but still the focus was primarily on disks. We had a disk focus, with Flash for acceleration. The big change with Exadata X3 is that we’ve increased the Flash memory capacity very significantly: we’ve quadrupled the amount of Flash memory.”
“Exadata X3 has been designed to work really well for all types of applications, including OLTP, warehousing, mixed workloads, and cloud”
“what is available today with Exadata is really just the beginning. We’re no longer focused on making the basic platform work , we’re now primarily focused on value add—things like improving consolidation, improving performance, improving compression—increasing the value of all the Exadata technologies even farther.”
The full article is available in the 106th issue of the NoCOUG Journal.
What’s your take on RDBMS and NoSQL?
My take is that application developers have belatedly but correctly concluded that an RDBMS is not the best tool for every application. For example, relational algebra, relational calculus, and SQL are not the best tools for graph problems. As another example, weblogs are non-transactional and don’t benefit from the ACID properties of the RDBMS. Amazon created the Dynamo key-value store for a highly specific use case. From the Dynamo white paper: “Customers should be able to view and add items to their shopping cart even if disks are failing, network routes are flapping, or data centers are being destroyed by tornados. … There are many services on Amazon’s platform that only need primary-key access to a data store. … Simple read and write operations to a data item that is uniquely identified by a key. Data is stored as binary objects (i.e., blobs) identified by unique keys. No operations span multiple data items and there is no need for relational schema. … The operation environment is assumed to be non-hostile and there are no security related requirements such as authentication and authorization.”
What’s your take?
P.S. I wasn’t always of this opinion because, until very recently, I had not studied NoSQL technologies. But my favorite quote is the one on consistency from Emerson’s essay on self-reliance: “The other terror that scares us from self-trust is our consistency; a reverence for our past act or word … bring the past for judgment into the thousand-eyed present, and live ever in a new day. … A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. … Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day.” (http://www.emersoncentral.com/selfreliance.htm)
However, I don’t give a free pass to the NoSQL camp. I believe that most of the problems that the NoSQL camp is trying to solve, with the sole exception of graph problems, could have been solved within the framework of relational theory. Since the relational camp couldn’t (or wouldn’t) solve the problems, the NoSQL camp came up with their own solutions and threw out the baby (relational theory) along with the bathwater (the perceived deficiencies of relational theory). My topic for the Great Lakes Oracle Conference is therefore “Soul-searching for the relational camp: Why NoSQL and Big Data have momentum.” (https://www.neooug.org/gloc/accepted-presentations.aspx)
The golden rule of NOT tuning SQL
Dear NoCOUG members and friends,
The golden rule of not tuning SQL is “operate with as little information as possible.” Not only will this increase your chances of failure but it will make it difficult for others to help you.
Every exercise in problem solving – no matter how little – has exactly six stages: Problem, Observation, Implication, Solution, Execution, and Documentation. I use the acronym POISED to remember the six stages. If you strive to operate with as little information as possible, you increase the chances that you will not progress beyond the Observation stage.
I recently saw a request for SQL tuning help (http://www.freelists.org/post/oracle-l/Query-tuning-help). The poster had provided the EXPLAIN PLAN output. You probably know that EXPLAIN PLAN output is not of much use in SQL tuning. He was asked to add the GATHER_PLAN_STATISTICS hint and provide the output of DBMS_XPLAN.DISPLAY_CURSOR (http://www.freelists.org/post/oracle-l/Query-tuning-help,7). The rowsource execution statistics in the DISPLAY_CURSOR output showed that hundreds of thousands of rows were being retrieved and then discarded. There was enough information to deduce the right joining order (http://www.freelists.org/post/oracle-l/Query-tuning-help,9) but not enough to explain why the query optimizer was not finding the right order.
The best tool for tuning SQL is SQLTXPLAIN because it collects all the information that is required for tuning SQL. The author of this tool is Carlos Sierra. He will be conducting a two-day SQL tuning master class at the CarrAmerica conference center in Pleasanton on February 19 and 20. He will also speak at our winter conference at the Oracle conference center in Redwood Shores on February 21. I hope that you can attend at least one event.
Kindest regards,
Iggy Fernandez
NoCOUG Journal editor
Recent Comments