The Use of Oracle Database - Case Study Example

Develop scenarios for assignments The first section of this paper will examine the use of oracle database 11g to store and maintain data by mentioning specific requirements to which this database has. The second part of the task will focus on five different scenarios where the students as oracle developers will develop an application for one of the scenario. In each scenario, the paper will provide detail requirements the will enable users to develop staff login screen, transaction form for inserting, updating and deleting records. Trough these requirements the users will also link forms together, use customized menu and develop some reports and call them from the forms. Oracle database is a relational database management policy that is widely used. It is deployed in enterprises of all size to run enterprise resource planning applications, data warehouses, repositories, e-commerce systems, business analytics and intelligence applications, and reporting systems. The extensibility to run oracle database on Amazon relational database service (RDS) is offered by Amazon Web Service (AWS). Many customers prefer RDS use for oracle since it provides a managed, easy option to run an oracle database on AWS without having to think about maintaining and installing database software or infrastructure positioning. An alternative way is running oracle database directly on Amazon EC2 that gives you full control over setup of the database environment and the entire infrastructure. This alternative provides familiar approach to run oracle database on AWS. It requires one to keenly tune, manage, configure and set up all components such as security, scalability networking and Amazon EC2 instances in an appropriate manner. The following are the type of scenarios for running oracle database On Amazon EC2. These scenarios include; standard architecture scenario, enterprise-class architecture scenario, large enterprise class architecture scenario, high-performance architecture scenario, and launch oracle architecture scenario. Standard Architecture scenario This scenario explains the general-purpose database deployment. It optimizes for low overall cost while putting emphasis on a good performance. The deployments for oracle database like small production application deployments, dev/test environments, reporting systems and customs projects are most applicable for this scenario. This kind of scenario is highly scalable hence, if the requirements change, it can be migrated to the other architecture scenarios. Scalability of this scenario is in three dimensions: database size, instance size and architectural. As the needs change, one can scale up the largest instance type available starting with the small Amazon EC2 instance like m1.small. This is done by stopping the database instance, then restart it with a new instance type. You can also increase database size up to 1 TB depending on the need. Changing the database size can be done by starting by starting with a database that is small and as the amount of data increases, you scale up the database size. This can be done by creating a snapshot of the enduring Amazon EBS volume used for data files and into the new larger volume attached to the instance, restore the snapshot. For database sizes 10 GB to 1 RB, this scenario is suitable and is designed for moderate overall database performance. It can be made to work best by selecting larger Amazon EC2 instance for running the database. Moderate I/0 performance of 100-4000 IOPS is provided by this kind of architecture scenario. It does not incorporate any specific database-level high availability like failover/ secondary database instance in order to keep the cost low. Disaster recovery (DR) is included by this kind of scenario. But in a bid to yield low cost, the disaster recovery for this scenario entails a manual process, and the result is a recovery time objective longer than the three other scenarios. Using the snapshot copy API, Amazon EBS snapshots of the backup volume are reproduced to a different region. It is designed to provide isolated; secure environment using Amazon VPC, thus instantiating the database Amazon EC2 instance within a private subnet with Amazon EC2 that is applicable. Enterprise Class Architecture Scenario For systems that require larger database size and better performance than the standard architecture scenario, then Enterprise class architecture scenario provides a better option. This is because it is formed for applications that require fault tolerance, availability, reliability, and enterprise-class performance. It is highly scalable thus it provides the capacity to start small and scale out to larger capacity depending on the load. If the requirements increase over time, Enterprise class gives the opportunity to migrate this scenario to one of the following architecture scenarios. The size of the database is highly scalable also. As the database grows, you can easily add Amazon EBS volumes to gain larger capacity since the storage used is a striped component of EBS volumes managed by oracle ASM. For database size 500 GB to 5 TB, this kind of scenario is suitable. This scenario is constructed to provide a moderate I/O performance of between 2500 to 10,000 IOPS and high-level performance. To support high availability, a secondary database server in another availability zone is set up and to facilitate synchronization Oracle data Guard is used. Data guard demands using oracle database enterprise edition. This architecture scenario can be used for standard one editions or oracle database standard if third-party tools that provide a similar function to oracle data guard. It gives the ability to recover from an AWS region-wide event. Using OSB and RMAN, database data is backed up to another AWS region. The process of data recovery in this scenario is manual. It involves the provision of scripts that manually trigger database Amazon EC2 instance to be created from AMI and database data from the RMAN backup in the other region is restored. The backup frequency determines the state and timing of the recovered database (RPO). Using Amazon VPC like in the previous scenario, isolation is provided and with applicable security organization rules in private subnets, database Amazon EC2 instances are instantiated. To make use of encryption at rest, one may use oracle transparent data encryption (TD). Large Enterprise Class Architecture Scenario This scenario is an improvement from the previous one; it distributes loads across multiple availability zones by use of Oracle Active Data Guard. In addition, in the case of DR event it uses "pilot light" disaster recovery pattern for quick recovery. In an enterprise, it supports almost any database use scenario. It is scalable in terms of both performance and database size. It suits database size of 2 TB to 20 TB. Large enterprise-class scenario is designed to give a high level I/O performance (8000-40,000 IOPS) and instance performance. Implementation of high availability is done using Oracle Active data guard in an another availability zone. Active Data Guard allows load distribution by use of replicated instance for read-only loads, unlike Data Guard. If there is a need, this architecture scenario allows for multiple read replicas thus increasing load distribution and availability making the architecture more scalable. In this scenario, “pilot light” Disaster recovery scenario is used, and it helps to provide very quick failover with no or minimal data loss while keeping the cost low. It provides isolated, secure environment using Amazon VPC and instantiating database Amazon EC2 instance within a private subnet with Amazon EC2 group rules that are applicable. To make use of encryption at rest, Oracle Transparent Data Encryption (TD) is used. High Performance Architecture Scenario This scenario is designed majorly for high I/O performance. It drags ephemeral (local) SSD drives to avoid network latency and to take advantage of very high IOPS. Based on Amazon EBS volumes for data reliability and safety, database uses ephemeral instance storage along with replicating another instance in the same availability zone. This architecture can switch rapidly over to the second instance due to failure of the primary instance hence preventing data loss and making the database continuously available. This architecture has limited scalability because it can be used only in Hi I/O instance type and limitation of the database size to the maximum size of occurrence storage available that is currently 2 TB. For database capacities, 5 GB to 2 TB, this kind of architecture is suitable. This scenario authorizes Amazon EC2 ephemeral SSD disks to take advantage of reduced network latency and very high IOPS. Implementation of high availability is done using two oracle active data guard instances, one in a different availability zone, and another in the same availability zone as the major database. In addition, it is also done for reliability where major instance bases on volatile instance storage while instances that are replicated using Amazon EBS storage. Using replicated instance for red only loads, active data guard enables load distribution. To keep the cost low while providing very quick failover with no or minimal data loss, this scenario uses a "pilot light" disaster recovery scenario. The designing of this architecture enhances provision of isolated, secure environment using Amazon VPC and instantiating database Amazon EC2 case within a private subnet with Amazon EC2 security organization rules that are applicable. Making use of encryption at rest involves the use of oracle transparent data encryption (TD). Conclusion An Amazon web service provides a highly flexible, cost-effective, resilient, reliable, and secure cloud-computing platform to run database scale. One can implement oracle database environment with minimal effort, cost-effectively and quickly using the scenarios. Reference Abdul Sathar Sait. (2012). Oracle Database 11g on Amazon EC2 Implementation Guide. Viewed on November 15, 2014, from http://media.amazonwebservices.com/AWS_RDBMS_Oracle_11g_on_EC2_Reference_Architecture.pdf Read More