- Introduction
- Availability Features
- Environmental and Hardware Features
- Database Engine
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Availability Features
One of the biggest selling points that Oracle has in its arsenal is the availability features of 9i. Oracle 9i is alleged to be the most reliable, unbreakable, and scalable RDBMS on the planet, if you listen to the marketing hype.
Oracle is a very mature product, and has been offering clustering support since the mid to late '80s. Compare that with SQL Server, which has only recently offered clustering, and you can begin to see why Oracle announces its RDBMS as being the most reliable.
NOTE
Some of the features discussed in this article are not available with all editions of Oracle 9i implemented on Windows 2000. You may need to purchase Oracle 9i Enterprise Edition in conjunction with Windows 2000 Advanced Server or Windows 2000 DataCenter.
Clustering Support
Clustering has been a core competency of Oracle and its products for a number of years. Oracle 9i is no exception. In fact, clustering support in Oracle's products is stronger than ever, allowing for longer uptimes and better support for ensuring that your systems are available whenever they're needed.
Unlike SQL Server, Oracle doesn't rely on Windows clustering (for Windows systems, of course), and so is not prone to the pain of setting up Windows clustering. As in SQL Server, however, there are two main types of clustering:
Active/active clustering. This is where an instance of Oracle actively runs on all nodes of the cluster. A passive instance of the Oracle database resides on each of the other servers in the cluster. For example, suppose that server A has database A actively serving requests to users, while server B has database B actively serving requests to users. A copy of database B resides on server A, but it doesn't actively service client requests, and vice versa for server B. Only when server A fails does the database instance failover, with that server B becoming the active server for both database A and B. This requires the hardware within the cluster to be capable of supporting multiple active instances, even if they never failover.
Oracle has made it easier to implement active/active clustering than in the past, which can help to ensure that your site remains available whenever needed.
Active/passive clustering. Unlike active/active clustering, active/passive clustering means that only one node in the cluster is active at any time. For example, if server A has database A, this is the only database that it has, and it actively services requests for this database. Server B also holds a copy of database A, but doesn't service requests unless server A fails. This requires hardware to sit idle, and therefore can be very expensive to implement.
Oracle has invested heavily in clustering and is extremely advanced in this area. Their real application clusters (RAC) allow your database tier to scale out without requiring code changes to your application. The database can be integrated into the cluster, rather than having the clustering at the operating system level. This allows for superior clusters that enable the session information to be failed over with the cluster. For example, in-progress SELECT statements can be failed over so that a client's query can still be returned, even if the node it was connected to is no longer available.
Oracle recognizes the need for ensuring that when a node fails over it is recovered quickly. Unlike operating system clusters, which must restart the failover database (with a large overhead on substantial databases), Oracle clusters can ensure that both databases are instantiated even if only one database is actively servicing client requests.
Shared-Disk Servers
Oracle prides itself on the ability to scale out without causing applications to be recoded or changed significantly, to allow for extra performance provided by additional processing power.
Instead of implementing federated database servers (see Part 3 in this series), Oracle 9i incorporates shared-disk servers. This architecture differs significantly from SQL Server's federated database technology (we'll take a closer look at the differences in later articles); however, both technologies allow you to scale out your database tier.
Shared-disk clusters require that each server involved in the cluster share access to the same disk, which allows all the servers to use the same data and database schema.
To scale out the shared-disk cluster, additional hardware needs to be purchased and installed, the new instance needs to be configured, and that's it! There are no other additional tasks, as the server accesses the same disk that holds all the data and schema information as the other servers involved in the cluster.
Transaction Log Shipping
SQL Server 2000 allows transaction logs to be shipped from one server to another, thus allowing a server in another location to be created as a "warm" standby. Oracle 9i uses a similar technology to create warm standby servers. However, in Oracle terms this is referred to as a loosely coupled cluster. One database server acts as the primary server (serving requests by users), and additional servers act as standbys, generally in alternate locations. As data is updated, the main server logs are sent to the secondary servers, allowing data changes to be applied.
With the new features in 9i, DBAs can specify the amount of data delay they want between servers (15 minutes, for example). This offers the DBA the ability to ensure that accidental data changes are not replicated around the server farm too quickly. Alternatively, the DBA can specify that servers are to be kept in sync continuously, ensuring that when a DML change is committed on server A, server B sees the change almost instantaneously.
Replication
Replication is the process of copying database objects and data to other database servers within a logical network. This allows users to work on a local copy of the data; at a later time, the user's changes are replicated back to other database servers. Even if a main site fails, users will still be able to work, because they have local copies of the data available.
Oracle 9i continues its support for replication. The replication topology allows the administrator to define groups of servers as a site. These sites can then be configured to use one of the following replication scenarios:
Materialized views. Materialized views allow a remote site to query replicated tables and objects locally, rather than traversing the network to resolve client queries. A materialized view can be configured in one of two ways:
Read-only. This configuration allows a user at a remote site to perform SELECT statements and to read information in the replicated objects. When changes are registered in the replicated table, the table is totally refreshed from the master site. This configuration eliminates data conflicts.
Updateable. The user works on a local copy of the replicated table, and changes are pushed to and pulled from the master site. Data conflicts may occur with this configuration. An updateable materialized view configuration is generally less network-intensive than multi-master replication (described next) because only a subset of the database is replicated around the topology. It also means that client sites can contain database servers that don't require as much storage capability as the multi-master configuration.
Multi-master. Each site within the replication topology can make DML or DDL changes (master site), and the transactions are then replicated (pushed) around to the other sites within the topology. The way that these changes are replicated around is configurable:
Synchronous. Any changes made at a master site are immediately replicated to all other master sites. This option can use more network bandwidth, but may result in fewer data conflicts. If a site in the topology fails, users can query data but not perform updates (commits to the database) until the site is recovered.
Asynchronous. Any changes made at a site are deferred and queued to be replicated at a specified time. This is generally how replication scenarios are set up; however, while reducing network usage, it can result in more data conflicts. Even if a site goes down, users can still work, as each site is autonomous from the other sites in the topology.
Procedural. Reduces the need to replicate large data changes to other sites. Procedural replication tracks the stored procedure calls that modify data and issues these calls to other sites within the topology. This reduces the need to push large volumes of data around the network.
Hybrid configurations (multi-master and materialized). To provide a very rich replication configuration, Oracle 9i supports hybrid environments. This allows solution architects (and of course businesses) to leverage the best from both materialized and multi-master replication. For instance, an organization can create multiple master sites (multi-master) with many sub-locations (groups) that only require a subset of data from a table to work on (materialized view).
When a change happens at the branch office, it's replicated to the closest master site, and then is replicated around the organization boundaries. This is very powerful, and gives organizations with multiple branch offices the flexibility they need without investing heavily in bandwidth.