I’ve recently put a couple of new articles about old subjects on the website. In both cases, the articles were initiated by forum questions, but the explanations became too painful in the format of a forum post so they graduated into articles…
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.
These non-core goals (for the lack of a better term for side effects of consolidation projects) can play a role of timing triggers but success of a consolidation project is defined by cost metrics. In real-life there are very few pure consolidation projects as project success criteria usually contain other conditions than cost cutting.
Tip: Keep costs at the heart of the consolidation project but don’t get blinded by cost alone! It’s a total failure if a consolidation project delivers a platform with much lower TCO but is unable to support the required availability and performance SLAs.
It’s also not very popular to run a purely cost-cutting project in a company — people are not overly motivated especially if it endangers their jobs. Luckily, most healthy businesses have quickly growing IT requirements and consolidation projects very quickly bust out of the scope of just cost savings.
Tip: Get your success criteria right and keep cost optimization as the core goal. If required, reduce the scope and split projects into stages where each stage has it’s own core goal. This way, you can classify some stages as purely consolidation. It’s so much easier to achieve success if there are only few criteria. You could also check mark success boxes constantly as you go instead of trying to get to the light at the end of the tunnel that could take years.
If you have anything to share on the scope of consolidation projects — whether past experience or current challenges — please, comment away.
Dear blog readers,
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?
I myself contributed the first chapter to this book but the rest of the authors are really awesome! ;-)
To win the book, you need to share your experience and provide details. Addressing the items I mentioned would be great but if you don’t have the whole picture, you might miss some of it so just tell us your story. Of course just few sentences won’t qualify you for a story teller so I’ll use 1000 characters as a guideline threshold to qualify for a draw but I won’t follow it blindly — insights into your consolidation project is what counts!
Don’t forget to enter a proper email address (remember that it’s not shared) when entering a comment so that I can follow up in case you get the prize.
Oh… and there is a deadline! You get time until tomorrow (at the time of writing) – 11:59pm EST 18-Jan-2011. Feel free to share even later but the prize will be gone by then!
Thanks in advance for all your comments!
After my recent series of postings, I was made aware of David Lutz’s blog on NFS client performance with Solaris. It turns out that you can vastly improve the performance of NFS clients using a new parameter to adjust the number of client connections.
root@saemrmb9> grep rpcmod /etc/system set rpcmod:clnt_max_conns=8
This parameter was introduced in a patch for various flavors of Solaris. For details on the various flavors, see David Lutz’s recent blog entry on improving NFS client performance. Soon, it should be the default in Solaris making out-of-box client performance scream.
I re-ran the DSS query referenced in my last entry and now kNFS matches the throughput of dNFS with 10gigE.
Collaborate 09 starts on Sunday, May 3 (a few days from now!) in Orlando. I’ve been offline for several weeks (more on that later), but will be returning to the world of computers and technology in full force in Orlando. I’ve had a few inquiries about whether or not I’ll be at Collaborate, so I thought I’d resurrect my blog with a post about where I’ll be and some of the highlights I see at Collaborate 09.
First, where I’ll be presenting:
The RAC SIG, Oracle and IOUG are thrilled to present the hands-on event dubbed “RAC Attack!” at Collaborate09 in Orlando, FL. It is a half-day University Session in the IOUG Forum scheduled for the morning of Thursday, May 7th.
Each participant will have their own private RAC cluster to use. You’ll be able to install a new cluster, test session failover, perform backup and recovery and just about anything else you’d like to try (time permitting). The session will have lab outlines with very specific instructions that cater to beginners. Advanced users are welcome to test anything they like. If you try something that doesn’t work, we have mechanisms in place to help “reset” your cluster in 15 minutes and let you continue working and testing.
Those of us that have dealt with RAC environments for a while are familiar with the behavior of Oracle Services in an Oracle Cluster. Services are an essential component for managing workload in a RAC environment. If you’re not defining any non-default services in your RAC database, you’re making a mistake. To learn more about services, I strongly recommend reading the definitive whitepaper by Jeremy Schneider on the topic.
This has been an interesting week, but not really that surprising.
I was called back to a previous client site where I had previously helped with some Oracle Application Server (10.1.2.2) post-install configuration. In that previous visit, I got oriented to the environment they use and the packaged application they were deploying. The packaged application uses JSP, Oracle Forms, and Oracle Reports (possibly also Discoverer). The deployment environment is all Microsoft Windows servers with two Oracle Application Server homes per application server since the vendor’s deployment requires that JSPs be deployed in a separate O_H from the Oracle Forms and Oracle Reports environment (that’s the first eyebrow-raise I did, but whatever).
This customer had an environment that was configured by the vendor for testing purposes and it works fine. However, it uses HTTP and they want to use HTTPS for all client-server traffic. They also wanted to be able to manage the environment and be better equipped to support it, so they left the vendor-installed environment as is and built a new environment on new servers so they’d get first-hand views of the install and configuration procedures. Since all the application servers are virtual machines, they could easily create additional machines.