I am supposed to be working on the next post for my PeopleSoft/RAC project, but decided to take a break from that and talk about OpenWorld. As just about anyone in the Oracle universe is aware, OpenWorld is September 19th to 23rd. This year I am doing three sessions along with helping to organize the User Group Forum on Sunday. Before that all gets going though, I'm hoping to catch the Milwaukee Brewers at the San Francisco Giants. I am a huge Brewers fan and I have never seen a game outside of Milwaukee. The Brewers are in San Francisco for a weekend series and I'm hoping to get to the game on Saturday evening. Anyone want to join me?
Sunday is again User Group Forum day at OpenWorld. The schedule is a little different and the sessions are not starting until 12:30 do to travel restrictions on Satruday because of Yom Kippur. IOUG again has eight rooms that we have schedule four sessions per room. In addition, Oracle is having MySQL Sunday during the same time at the Marriott. IOUG will be participating with some sessions there too. This will split the audience a little bit on Sunday, but we are hoping for huge crowds at both events. Check out the IOUG list of sessions or via Schedule Builder or Content Catalog on the OpenWorld site.
My personal schedule is already busy as usual. I will be helping out at the IOUG booth again along with various meetings. Plus, I am involved with three sessions this year. For the User Group Forum on Sunday, I will be leading a round table discussion about Linux. We will have several users as well as people from the Oracle development team. This has been a very interesting and well attended session in years past. People have had many questions and there is a lot of information sharing that takes place. If you are an Oracle user that has anything installed on Linux, this should be a very informational sessions. Come and learn about Linux and also share your experiences.
Recently, my company updated our PeopleSoft application. As our PeopleSoft Administrator (PSA) likes to say, "we did a minor upgrade." That "minor" upgrade included PeopleTools 8.49 to 8.50.08, Application Bundles from 25 through 28, and implementing Multi-Language. We are toward the end of phase 2 of the project, which is to move to Oracle Real Application Clusters (RAC) for the database. The PSA that was in charge of phase 1 and I are doing a presentation on the overall project. This should be fun because we should be crossing a large number of functions and users. The title is more about PeopleTools 8.50 which is fine because I think it will draw a big crowd.
When we decided to replace our PeopleSoft database server we went through an evaluation process to determine the best solution. As part of that evaluation, we decided to use Linux as our database operating system. I have been a Linux person for several years and had to convert our HP-UX system administrator into an accepter of Linux. As part of that conversion, he and I will be doing a Linux session with the Linux product team from Oracle. They will lead in with how the support model is supposed to work and what is included. We will finish up with how it all really works.
That's my current wrap up for OpenWorld. I'm hoping to see a lot of people that I only get to see a couple times a year. I also get to meet new people every year and it blows my mind how many people are out there that are doing some really cool stuff. If you are planning on attending, let me know and check out the User Group Forum on Sunday!
Tuesday, July 27, 2010
Saturday, July 10, 2010
Oracle RAC For PeopleSoft - Part 1
So it's been several months since my last blog entry. Things have been crazy at work, at home, and with IOUG and unfortunately, blogging is somewhat low on the priority list. So, what have I been up to? Well, the home life would be enough for its own blog with two kids that are very involved in sports. That is another story though. Work has been very interesting with a couple projects. The one I am in the middle of now is implementing Oracle Real Application Clusters (RAC) to support our PeopleSoft database.
I have been a DBA for about 13 years. It is almost crazy to say that, but okay, I accept it. I am on my second time around supporting a PeopleSoft environment. I work for a company that is made up of many divisions and is part of a larger organization made up of several companies. We have been consolidating financial systems into a PeopleSoft 9.0 Financials system from our divisions, and recently, from one of our sister companies. Not only is it a challenge to integrate business processes between divisions and companies, but technically, we have been challenged to find a solution that will grow as we continue to consolidate. The biggest part of that challenge is that we are not sure, from an IT perspective, when we will be consolidating. We do not want to oversize our architecture now for where we are, but do not want to undersize for future growth.
Performance of the PeopleSoft database has been questionable since I started at this company two years ago. We have done quite a bit with indexes, changing some business processes, and actually changing some of the application processes. A couple big wins involved converting PeopleSoft "temp" tables to Oracle temporary tables. Even with all the tuning successes, adding many users through growth and consolidation has made it very apparent that we have outgrown our database environment. This is really not bad considering the environment was implemented over three years ago with limited information.
Given that we had exhausted most of our tuning options and we knew we were bringing on new projects and users, we decided that new hardware was required. The decision came down to a new, dedicated database server or Real Application Clusters. The company is still working to consolidate IT operations, so we are not sure what divisions or how many users we will be supporting over the next three to five years. Since we did not want to suggest spending several hundred thousand dollars on a new server this year, only to have to do it again in a year if we consolidated with another large division, RAC was the logical choice.
This entry has been in the works for several weeks and is getting long enough. In the coming entries I will talk about how we put together a proof of concept, designed the architecture, built the environment and how the implementation is going. Stay tuned. I will make sure the follow-up entries are faster in coming than this one...
I have been a DBA for about 13 years. It is almost crazy to say that, but okay, I accept it. I am on my second time around supporting a PeopleSoft environment. I work for a company that is made up of many divisions and is part of a larger organization made up of several companies. We have been consolidating financial systems into a PeopleSoft 9.0 Financials system from our divisions, and recently, from one of our sister companies. Not only is it a challenge to integrate business processes between divisions and companies, but technically, we have been challenged to find a solution that will grow as we continue to consolidate. The biggest part of that challenge is that we are not sure, from an IT perspective, when we will be consolidating. We do not want to oversize our architecture now for where we are, but do not want to undersize for future growth.
Performance of the PeopleSoft database has been questionable since I started at this company two years ago. We have done quite a bit with indexes, changing some business processes, and actually changing some of the application processes. A couple big wins involved converting PeopleSoft "temp" tables to Oracle temporary tables. Even with all the tuning successes, adding many users through growth and consolidation has made it very apparent that we have outgrown our database environment. This is really not bad considering the environment was implemented over three years ago with limited information.
Given that we had exhausted most of our tuning options and we knew we were bringing on new projects and users, we decided that new hardware was required. The decision came down to a new, dedicated database server or Real Application Clusters. The company is still working to consolidate IT operations, so we are not sure what divisions or how many users we will be supporting over the next three to five years. Since we did not want to suggest spending several hundred thousand dollars on a new server this year, only to have to do it again in a year if we consolidated with another large division, RAC was the logical choice.
This entry has been in the works for several weeks and is getting long enough. In the coming entries I will talk about how we put together a proof of concept, designed the architecture, built the environment and how the implementation is going. Stay tuned. I will make sure the follow-up entries are faster in coming than this one...
Subscribe to:
Posts (Atom)
