Pythian is very excited to return to the much-awaited RMOUG 12 held in Denver, Colorado from February 14-16, 2012. Keep your eyes open for Alex Gorbachev, Marc Fielding, Don Seiler and Gwen Shapira in attendance. We have a fantastic line-up of speakers this year featuring a total of seven papers presented by Alex, Marc, Don and Gwen. If you have any feedback on our sessions, please send your comments directly to the speaker or to Vanessa Simmons, Pythian Director of Marketing. Please also follow this link to sign up to receive notice of future speaking engagements, webinars or Pythian news.
Be sure to stop by our booth (#3,6,7,10) to say hello to our friends from the OakTable Network, and enter our draw to win the new Amazon Kindle with software provided by Cary Millsap (MR-Trace, MR-Tools & Method-R Profiler) and a pack of digital e-book downloads courtesy of Apress. Also slated is the RAC Attack workshop, which was first offered at Oracle Open World and UKOUG, and is now in its second year at RMOUG. Pythian is co-sponsoring this event with Apress and it’s a fun and informative way to learn from our experts how and when to properly build a RAC environment.
“Hello World!” I guess that’s the most appropriate way to start my 1st blog post under pythian.com domain. I’m going to start slow, but hopefully will pick up speed and have at least couple of posts each month to share with you. I’ve been blogging at http://appsdbalife.wordpress.com until now and I haven’t decided yet what the future will be for my previous blog, I wouldn’t like it to become some kind of a zombie page that’s been long dead but still wandering around the internet world.
Enough intros, let’s get to business! I hope this blog post doesn’t get lost in the huge amount of posts related to OOW 2011.
A few days ago I was asked to estimate how much space needed to be added to the ASM diskgroup to handle the database growth for one year without additional need of adding disks. Obviously, to estimate the disk space that needed to be added I had to know what the DB size will be in one year from now. It looked like an easy task as I knew we were recording the size of the database every day. Read the rest of this entry . . .
Oracle Database Appliance (ODA) is in many ways similar to an Exadata quarter rack: they both use two similar compute servers in an engineered system configuration, with shared storage and flash storage. But in other ways, especially networking and storage, they differ significantly. In particular:
Storage connectivity: ODA uses SAS direct attachment, while Exadata uses an InfiniBand backbone connected to dedicated storage servers
Flash memory: Exadata has significantly more flash memory than ODA does. While both can store ASM diskgroups in flash, Exadata also has flash cache capability. ODA’s default configuration uses flash to store redo logs; this helps compensate for ODA’s lack of
battery-backed disk write cache in the latency-sensitive redo write workload.
Expandability: ODA currently comes in a single 2-server, 12TB configuration. An Exadata quarter-rack configuration has
2 compute servers and a minimum of 21TB raw storage. Both compute capacity and storage are expandable virtually without limit, given sufficient number of racks and network backbone.
I’ve started putting together some information about the Oracle Database Appliance in question-and-answer form. If you have an unanswered question, ask away in the comment section below.
When I first heard about Oracle Database Appliance and what it does, I got really excited — I saw great potential in this product. When we got our hands dirty and started testing the appliance, I become confident that this product will be a hit. Now it’s finally the time when I can share my thoughts and experience along with other Pythian folks.
This article is targeted primarily on system architects and managers explaining what they get with Oracle Database Appliance as well as what they don’t get.
So what you do get with Oracle Database Appliance
This is why you would want the appliance — if some the bellow solves your headache.
Standard platform — highly repeatable solution
Oracle Database Appliance is the same hardware, same software up to the drivers, components firmware, hardware components revisions and etc — the same for all customers around the world. This means that you are very unlikely to encounter unique infrastructure issues. You will take advantage of all customers’ experience running Oracle Database Appliances in their data-centers. This is similarity to Exadata platform but Oracle Database Appliance has even less variations so more leverage from standards. Read the rest of this entry . . .
Fahd states that “Oracle Exadata Database Machine” has most changed his life – changing the game, and setting very high standards of performance, support, scalability, reliability and unification.
Shout out to Fahd from your peers at Pythian!
I guess there might be just a little truth to Pythian’s growing reputation as an “Oracle ACE Factory” ;), as recently mentioned by Justin Kestelyn in the May 11, 2011 OPN PartnerCast:
Please join me in congratulating Fahd by adding a comment below.
Ranking Canada’s Fastest-Growing Companies by five-year revenue growth, the PROFIT 200 profiles the country’s most successful growth companies. Published in the Summer issue of PROFIT and online at PROFITguide.com, the PROFIT 200 is Canada’s largest annual celebration of entrepreneurial achievement.
Pythian is also happy to announce the official opening of our Toronto, Canada office and the expansion of our local GTA team to include Regional Sales Director, Colin Thompson (previously with Oracle).
As the birds have started their yearly migration back to their homes from the warmer areas to the relative less cooler areas in summer, bloggers are also touching base with the technologies which they cherish most and coming back with some master strokes. This new cool edition of Log Buffer, the coolest blog carnival covering hottest topics encompass that home coming. Now Chill with Log Buffer #222!!!
Back in February, Jonathan Gennick asked me if I would be interested in writing a bit of content for an APRESS brochure to distribute at RMOUG Training Days. I thought it was a cool idea and chose the topic of database consolidation. I only needed 10 short tips but when I started to write, it was difficult to stop — clearly, expressing ideas in concise way must not be my strength.
Jonathan did heavy edits and turned my draft into 10 brief tips and, of course, quite a few details had to go as we shrank the size 3-4 times. Since I’ve already put my efforts into writing, I figured I could share it as well on my blog. Thus, welcome the first blog post from the series of database consolidation tips. Let’s get down to business…
While there are often multiple goals of a consolidation project, the main purpose of consolidation is to optimize costs which usually means minimizing the Total Cost of Ownership (TCO) of data infrastructure. Your current hardware might be past end of life, you might lack capacity for growth, your change management might be too slow, etc. Read the rest of this entry . . .
I’m working on a small story about database consolidation and interested to learn what are success and failures that others are going through. While we have our own experience at Pythian, I find it interesting to learn about what others are going through. If you have enough details, it would be nice to see your feedback along those lines.
1. Why consolidation project started – targets?
2. What were expectations / success criteria and how they were set?
3. What was the scope of the consolidation project.
4. Expected time-frame and whether you are done by now.
5. Was the project considered successful? Goals met (see item 2)?
6. What were the measurements before and after? Were there any?
7. Issues faced and how they were solved or worked around.
….
Interesting facts like platform, number of databases, versions, consolidation strategy and etc.
….
Sharing your experience here would be beneficial for the community at large. Besides, don’t you want to win a book? Read the rest of this entry . . .
