deleted RAC para

Author: dlepow

articles/virtual-machines/workloads/oracle/oracle-reference-architecture.md

@@ -55,8 +55,6 @@ Customers generally require a high SLA for running their mission-critical applic
 
 When running Oracle databases across multiple [availability zones](../../../availability-zones/az-overview.md) when using Oracle Data Guard or GoldenGate, customers are able to get an uptime SLA of 99.99%. In Azure regions where availability zones aren't yet present, customers can use [availability sets](../../../virtual-machines/linux/manage-availability.md#configure-multiple-virtual-machines-in-an-availability-set-for-redundancy) and achieve an uptime SLA of 99.95%.
 
-Oracle RAC is currently not certified on Azure. To help protect against instance-level, rack-level, and data center-level failures, Azure offers availability zones and planned maintenance windows in addition to Oracle offering Data Guard, GoldenGate, and Sharding for high performance, availability, and resiliency for mission-critical workloads.
-
 > [!NOTE]
 > You can have an uptime target that is much higher than the uptime SLA provided by Microsoft.
 
@@ -204,7 +202,9 @@ This setup prevents data loss if an instance-level or availability zone-level fa
 
 In the preceding architecture, a GSM/shard director is deployed in every availability zone for high availability. The recommendation is to deploy at least one GSM/shard director per data center or region. Additionally, an instance of the application server is deployed in every availability zone that contains a shardgroup. This setup allows the application to keep the latency between the application server and the database/shardgroup low. If a database fails, the app server in the same zone as the standby database can handle requests once the database role transitions. Azure Application Gateway and the shard director keep track of the request and response latency and route requests accordingly.
 
-From an application standpoint, the client system makes a request to Azure Application Gateway (or other load-balancing technologies in Azure) which redirects the request to the region closest to the client. Azure Application Gateway also supports sticky sessions, so any requests coming from the same client are routed to the same application server. The application server uses connection pooling in data access drivers. This feature is available in drivers such as JDBC, ODP.NET, OCI, etc. The drivers can recognize sharding keys specified as part of the request. [Oracle Universal Connection Pool (UCP)](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjucp/ucp-database-sharding-overview.html) for JDBC clients can enable non-Oracle application clients such as Apache Tomcat and IIS to work with Oracle Sharding. During the initial request, the application server connects to the shard director in its region to get routing information for the shard that the request needs to be routed to. Based on the sharding key passed, the director routes the app server to the respective shard. The application server caches this information by building a map, and for subsequent requests, bypasses the shard director and routes requests straight to the shard.
+From an application standpoint, the client system makes a request to Azure Application Gateway (or other load-balancing technologies in Azure) which redirects the request to the region closest to the client. Azure Application Gateway also supports sticky sessions, so any requests coming from the same client are routed to the same application server. The application server uses connection pooling in data access drivers. This feature is available in drivers such as JDBC, ODP.NET, OCI, etc. The drivers can recognize sharding keys specified as part of the request. [Oracle Universal Connection Pool (UCP)](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjucp/ucp-database-sharding-overview.html) for JDBC clients can enable non-Oracle application clients such as Apache Tomcat and IIS to work with Oracle Sharding. 
+
+During the initial request, the application server connects to the shard director in its region to get routing information for the shard that the request needs to be routed to. Based on the sharding key passed, the director routes the app server to the respective shard. The application server caches this information by building a map, and for subsequent requests, bypasses the shard director and routes requests straight to the shard.
 
 ## Patching and maintenance