Oracle Web Listener

Second component of Web architecture is the Web Listener

Oracle Web Listener

1. The Web Listener receives incoming requests
2. The Web Listener submits incoming requests in the web request broker for processing.
3. The Oracle data is retrieved and the web request broker builds the HTML or JSP page.
4. Web Request Broker hands the page back to the web listener.
5. The web listener then sends the completed HTML documents back to the originating requester.

Oracle Performance Tuning: A Comparative Evolution from Oracle 9i to Oracle 13c

Query Optimization

1. Oracle 9i: In Oracle 9i, query optimization was largely rule-based or utilized the older Cost-Based Optimization (CBO) models. The DBA would often need to manually gather statistics and might even resort to query hints to influence the optimizer's behavior.
2. Oracle 13c: Fast-forward to Oracle 13c, the optimizer has become more sophisticated, leveraging a feature called Adaptive Query Optimization. This feature allows the optimizer to make real-time decisions on executing SQL queries, and it can even re-optimize a query in the middle of execution if the initial assumptions do not hold true.

Indexing

1. Oracle 9i: The role of indexes in Oracle 9i was somewhat limited to B-tree and bitmap indexes. The choice was often binary; B-tree for OLTP and Bitmap for OLAP.
2. Oracle 13c: The concept of indexing has expanded greatly. Advanced indexing options such as function-based indexes, domain indexes, and invisible indexes offer better ways to optimize performance. Partitioned indexes are also now in play, allowing data to be logically segmented for better access speed.

Memory Management

1. Oracle 9i: Oracle 9i primarily used manual memory management. The initialization parameters for the System Global Area (SGA) and Program Global Area (PGA) had to be set explicitly, requiring frequent tuning exercises.
2. Oracle 13c: Oracle 13c introduced the Automatic Memory Management (AMM) and Automatic Shared Memory Management (ASMM), significantly reducing the overhead of manual memory allocation. These features adjust memory dynamically, minimizing the need for manual intervention.

Diagnostic and Tuning Tools

1. Oracle 9i: Oracle 9i relied heavily on manual tools like Explain Plan, Tkprof, and Statspack for diagnostics. Performance tuning was more of an art, requiring a significant understanding of the underlying architecture.
2. Oracle 13c: With Oracle 13c, tools like Oracle Automatic Workload Repository (AWR), Active Session History (ASH), and Oracle Real-Time SQL Monitoring provide more in-depth diagnostics and recommendations. These are part of the Oracle Diagnostic and Tuning packs, offering automated capture of database performance metrics and enhanced visualization.

Concurrency Control

1. Oracle 9i: Oracle 9i employed basic concurrency control mechanisms, such as locks and latches. While these were efficient for their time, they required manual tuning for optimal performance.
2. Oracle 13c: In Oracle 13c, more advanced features like the Result Cache, Materialized Views with Query Rewrite, and Optimistic Concurrency Control significantly improve data access and manipulation, reducing the need for frequent locking and latching.

Cloud Integration

1. Oracle 9i: Oracle 9i predated the widespread adoption of cloud computing. Thus, performance tuning was strictly an on-premise affair.
2. Oracle 13c: Oracle 13c allows seamless integration with Oracle Cloud, introducing cloud-specific performance tuning options. Features like Database as a Service (DBaaS) and multi-tenant architecture have added another layer of complexity and options for performance tuning.