Hello, and welcome to Built and Deploy, a technical video series for cloud architects. My name is Monica McGowan, and I'm a Solutions Manager on Oracle's Managed Cloud Services team. Today, I'm thrilled to be here with Sambu Degosh, Technical Lead at Albertsons. We're here to talk about how Sam and his team are helping the company to scale its payroll up. operations for its 300,000 employees since they moved the on-premises PeopleSoft payroll application to Oracle Cloud Infrastructure.
Who are the different users of the PeopleSoft payroll application? Whoever works in the stores, the store managers, directors. We have warehouses.
We do have data centers. So there are a lot of places from where the employees access the PeopleSoft application. Inside the San Jose availability domain, We have all the application and management servers needed to support the payroll application in the application subnet.
On the PeopleSoft side, we have web and application servers. PUM servers are provided to support the PeopleSoft upgrade process. Batch processes, like your payroll run, have their own set of dedicated servers. And PeopleSoft also supports search capabilities using the elastic search function. Albertsons also use utilizes several third-party products, which are installed alongside the PeopleSoft servers.
Sam, can you tell us a little bit about the third-party products that you're using? So in terms of third-party product, we use ESP, which we use for scheduling. We also use something called Mentis, which we use for data masking for our lower environments to make sure we have some of the columns which are classified as PII-sensitive data, they are masked so that it is...
is not production data that you look at in the lower environments. We also use STAT, which is a Quest product that we use for migration. We use that for change control as well as for version control. Also located in the application subnet is a set of utility and support servers which are used by our managed services team to support the entire tenancy.
Now let's jump to the bottom of the diagram where we have the database subnet. Albertsons chose to use Database as a service to support these third-party tools, and these databases run on less costly virtual machines. For PeopleSoft, Albertsons chose Exadata Cloud Service, utilizing high-performing quarter rack Exadata systems, which support two database nodes and utilize Oracle Real Application clusters, or RAC. Let's spend a little time reviewing the Exadata deployment now. Can you describe what you guys have experienced with your payroll run since you've migrated to Exadata?
This is one of the very critical applications, and we wanted to make sure all the different divisions, pay groups, they get paid within a proper timeframe. And the Exadata migration helped us immensely in that front. So we have seen almost a 40 to 50 percent gain in the performance.
And the overall time that... it takes to run payroll has also improved a lot. So it has been a great benefit for us. Now, in the production environment, the PeopleSoft database resides across both database nodes using Oracle RAC. This Exadata is dedicated to production processing only.
However, in the disaster recovery or DR region, we have two additional Exadata quarter racks. DR is supported by using rsync for the non-database components. and Oracle Data Guard replication for the database. The DR environment is deployed with the identical configuration as production with one exception. The DR database is located on one of these Exadata servers, but shares this Exadata with a collection of non-production environments.
So during normal day-to-day operations, we have the DR database sized down so that it can process the incoming replication. Exadata are primarily allocated to support several non-production environments. We use the term sacrificial DR for this type of configuration. During DR testing or during an actual DR failover, we will shut down the non-production environments on that server and then resize the DR database resources to production capacity.
The second Exadata in the DR region is dedicated to non-production workload only, supporting functions like regression, performance and unit testing. Any key non-production environments needed for support during a DR scenario can be brought up on this second Exadata. Sam, can you share your thoughts around the DR solution in place?
What has improved, perhaps? So when we discussed about the DR solution, we really liked the concept of the sacrificial DR, which you were explaining, Monica, which we could resize, like we could downsize, we could upscale it as and when required. And that really helps us in maintaining the DR on the same Exadata rack as other non-prod systems as well. During an actual DR scenario, we can always upscale it back to... whatever a full production looks like and that definitely will help us in future.
Like no one expects a DR to happen but if they do we always think like this kind of solution will be beneficial to them. What was the biggest challenge you had in migrating to OCI and what was your experience in working with our transition team? Initially we had a tough time understanding the access protocols, the different way we are going to access the servers, how are we going to add a user, remove a user who needs access to the servers? What would be the development protocols? How can we migrate code over to different environments?
But there was a huge team behind making sure our support team, our infosec team who were concerned about the security aspect of it, explained things very clearly to them to make sure they have a good understanding of how things are going to work once we are on OCI. That's great. On behalf of the ACS team, at Oracle who have been working closely with Albert since.
I would like to thank you very much for joining today. This has been Built and Deployed. Thank you for joining us and stay tuned for more technical conversations with our OCI customers. Thank you, Ma. Thank you, Sam.