Upgrades

If you already have Oracle Application Express installed and wish to upgrade the version of Application Express, you should consider the following:

Versions and Patch Sets

Oracle strongly recommends that you regularly upgrade to the latest version of Application Express available from the Downloads page. The majority of bugs reported against Application Express are listed on the Known Issues page for the related release. Where possible a patch set is made available for a bug to enable those running the latest version of Application Express to update their installation. In between major versions there are often point releases, for example Application Express 4.2.1, which correct bugs and incorporate all of the patch sets released to that point in time, but do not introduce new functionality. Patch sets and point releases are available for download from My Oracle Support.

Note: If upgrading from an earlier release of Application Express, for example from Application Express 4.1 to Application Express 4.2.1, then you can simply download the latest files from the Download page. However, if you are upgrading from Application Express 4.2 to Application Express 4.2.1 then you must download the point release from My Oracle Support.

When you install Oracle Database 11gR2, Oracle Application Express 3.2.1 is included by default. Similarly, Oracle Database 11gR1 came with Application Express 3.0.2. In all scenarios the latest release on the Downloads page should be installed as soon as possible as it includes additional features, plus numerous functional and performance improvements, combined with the latest bug fixes.

To determine which version of Application Express you are currently running, log in to your Application Builder environment. On the home page, the current release will be shown in the bottom right corner. Only one version of Application Express can be configured into a single Oracle Database server. If you wish to run different versions of Application Express you will need to run each in a separate Oracle Database. You can import an application exported from a prior release, however, if you export an application from Application Express 4.2.x then you will not be able to import it into any prior release.

Schemas

The Application Express engine consists of a large number of Oracle tables and thousands of lines of PL/SQL programs residing within their own version specific schema. Application Express 4.2.x is installed into the APEX_040200 schema, Application Express 4.1.x is installed into the APEX_040100 schema. For Application Express 3.1.x and prior releases the schema is named FLOWS_xxxxxx.

You utilize the same installation procedure and files, downloaded from OTN, whether inserting Application Express for the first time or updating a previous release. The installation script checks for the latest existing Application Express schema and automatically copies the metadata, for the instance, workspaces, and applications, from the previous schema into the APEX_040200 schema. The original schema associated with the previous release is left completely unaltered. Following best practices, Oracle recommends that you create new tablespaces for the new release of Application Express and follow the appropriate installation instructions as outlined in the documentation.

Applications

When a new release of Application Express is installed all of the existing applications built into the previous release are automatically updated to run in the latest release. However, the intent of the Application Express development team is to not change the user interface as a result of an upgrade. As a consequence, application components that may alter the user interface are left untouched by the upgrade. It is the responsibility of the developer to manually review such components and update them or leave them running as before. Examples include new features added to interactive reports, charts (charts that utilize 'Custom XML' must be updated manually otherwise the custom XML will be lost), certain validations, and so on. In order for you to review the impact of these component upgrades, go to the Application Builder for each application upgraded and select Utilities > Upgrade Application and then review each upgrade type. You can easily upgrade the non-upgraded component for one, all, or a selection of the instances of that component from these pages. Please remember that updating the user interface of an application may require changes to existing application documentation / training guides and may also require that end users are retrained if the pages are significantly different.

The Oracle Application Express Advisor (Advisor) enables you to check the integrity and quality of your Oracle Application Express application. Advisor functions like a compiler or LINT and flags suspicious behavior or errors. Running Advisor checks the integrity of your application based on the underlying metadata. Each subsequent release of Application Express further tightens the rules engine, such as invalid developer code that was ignored previously may now produce an error. The Advisor will identify these issues as errors, along with numerous other warnings, to improve the quality of your applications. Therefore, Oracle strongly recommends that you run the Utilities > Advisor for every upgraded application.

Within each application, you can also specify the Compatibility Mode in the Application Definition, which changes certain runtime behaviors. The options include Pre 4.1, 4.1 and 4.2. Read the associated item help to determine the appropriate Compatibility Mode and the implications for upgraded applications.

Testing

The amount of regression testing required as part of upgrading Application Express is dependent on the complexity, size and number of applications upgraded. The majority of "complex" pages, including those that incorporate significant JavaScript or extensive PL/SQL computations and/or processes, should be included in regression testing. Developers should ensure pages which they manaually updated based on the Upgrade Application or Advisor are also included in regression tests. Not all remaining pages have to be included in regression testing, however, Oracle recommends you include a good representation of different page types includes reports, charts, and forms. An application should always be included in regression testing if its compatibility mode was modified post-upgrade.

While regression testing of upgraded applications is imperative to minimize risk of disrupting the end-users, it is important that such testing is not drawn out for an extended period. Generally, the development environment is upgraded first, allowing developers to review the applications and make initial updates as necessary or desired. Then the QA / Test environment is updated and the upgraded applications from development are built into this environment. Until such time as the Production environment is also updated it is often difficult or dangerous to make changes to production applications to resolve a bug or develop new functionality.

Clean-up

Following the successful upgrade of all of the environments to the latest release of Application Express, you should clean-up the environments. Once you start developing with the newer release, the Application Express schema associated with the prior release can be deleted. If you installed the prior release into a separate tablespace, you can simply drop the specific tablespace. Oracle recommends leaving the old Application Express schema(s) for a few weeks and then removing them from the Development, QA / Test, and Production environments. This clean-up releases disk space and ensures that no one accesses an outdated schema using tools such as SQL Developer or SQL*Plus.

Reverting to a Previous Release

One of the major benefits of Application Express automatically creating a new schema for each major release of Application Express is that reverting back to a prior release is a relatively simple and low risk option. If you revert back to a prior release, any modifications made in the Application Express 4.2 instance will be lost. The main task is to switch the public synonyms and grants to point at the previous schema instead of the APEX _040200 schema. The exact steps are outlined in the Oracle Application Express Installation Guide, Appendix A: Oracle Application Express Troubleshooting section. It is also important to remove the APEX_040200 schema once tests running on the prior release are successful.

Deploying Applications

You should review the Oracle Application Express Builder User's Guide, Deploying an Application documentation. The following sections cover additional considerations when deploying Oracle Application Express applications:

Environments

When developing with Oracle Application Express you should follow standard system development lifecycle practices in so far as having different environments for development, testing and production. Developers should only be allowed to make changes to applications and related database objects in the development environment. To further enforce this policy it is recommended that you install "Runtime Only" Application Express in the test and production environments. This will prohibit developers from accessing the Application Builder and SQL Workshop in these environments. Database Administrators (DBAs) should be the only ones with permission to update the test and production environments.

Database Objects

Often developers will need to create, modify / replace, or delete various database objects such as tables, packages, grants, etc. as part of a unit of work. Sometimes data will also need to be inserted, updated or deleted from one or more tables. Developers should create data definition language (DDL) and data manipulation language (DML) scripts as required so that any changes to database objects or data is reproducible. These scripts should be tested and checked into source control. Alternatively, developers can utilize Supporting Objects to define installation, upgrade and removal scripts. Supporting Objects is most valuable when developing applications that will be installed by third parties, such as the Packaged Applications. For other development activities having the DDL and DML scripts outside of specific applications, and not using Supporting Objects, provides more flexibility and control for the DBAs.

Creating a Build

Exporting an application from Application Express is very straightforward and produces a readable script file with a .SQL extension. This SQL script can be run in any Oracle Application Express environment which is the same release or higher of Application Express from where it was exported. For example, an application exported from Application Express 4.0 can be imported into an environment running Application Express 4.0, 4.1, or 4.2. However, an application exported from Application Express 4.2 cannot be imported into an environment running Application Express 4.1 or earlier. An application export includes the application definition, supporting objects, and shared components, including plug-ins. However, an export does not include images, CSS files, JavaScript files, etc. which must be managed independently.

Instead of exporting complete applications you can also choose to export specific components, such as a page. This also creates a SQL script file. There are limitations with importing components into a different environment from which it was exported. As a best practice, it is better to export complete applications rather than components.

If you wish to export an application and there are components, such as pages, that are not yet ready for testing then you can utilize "Build Options" to include or exclude various application components. Review Oracle Application Express Builder User's Guide, Using Build Options to Control Configuration to learn about the mechanics of using build options to customize an application export. The Application Express development team uses this capability extensively, especially when building Early Adopter releases where certain components may not be functionally complete.

Moving to Test / Production

Once developers have completed a suitable unit of work they should export the application(s) from the Application Builder and check them into a source control system. To make it easier to identify the unit of work it is often best to define a version by editing the Application Properties for the required application(s). Other required components such as images, CSS files, JavaScript files, etc., together with DDL and DML scripts should also be checked into source control. Developers should fill-out a build sheet, with all the required components and their locations in source control, so that the DBAs can build the release into the Test / QA environment. Once testing has been completed then the DBAs should be given a build sheet for the production environment.

Versioning / Application Backups

The Application Express installation includes two Java programs that enable you to perform either complete application exports or component exports. More details on these Java programs are available in the utilities / readme.txt file included within the installation. These programs are best utilized as part of a CRON job, or similar, that runs nightly and places the exports directly into a source control system. The exported files should be used as backups in case of a database corruption, etc. It is still best to manually export applications and check them into source control for deploying the applications.

User Interface

Oracle Application Express 4.2 introduced the ability to define multiple user interfaces for desktop and mobile devices. The sections below provide an overview of different design considerations:

User Interface Design

The optimal user interface design principles have continually changed and evolved as new architectures are introduced. Old mainframe applications screen design was based on keyboard input only and the order of items on a page was critically important. However, with client server applications user interface design generally placed multiple items on a single line and everything had to fit into a single screen with no scrolling. With Web applications the principle design changed again to very few items on a single line, instead using vertical scrolling as required. Now with mobile and tablet applications the user interface principles have changed again to display minimal information with very easy to navigate screens that utilize touch instead of pointing devices.

Application Express 4.2 introduced the ability to declaratively define mobile applications using jQuery Mobile. The Application Builder has been enhanced to support multiple user interfaces, both desktop and mobile, within a single application. Therefore, developers can choose to build an application only for the desktop, only for mobile, or for both. Each user interface defined for an application has its own theme, login page, home page, and global page (formerly Page 0). When defining a page within an application, you must specify which user interface is associated with that page. Based on the user interface selected the available page and region types varies, and the options available through the create page and region wizards varies accordingly. For example, maps, data loading and other page types and interactive report regions are only supported on desktop pages. Similarly on mobile pages the most common construct is list and form, instead of report and form.

Mobile Applications

Mobile applications are those designed to run specifically on smartphone devices. To facilitate this applications need to be built with extremely minimal, semantic HTML that is optimized for mobile connections. Oracle Application Express 4.2, and above, incorporates jQuery Mobile to allow developers to rapidly build mobile applications. jQuery Mobile based web pages use a framework that was specifically built for mobile devices. jQuery Mobile is a lightweight framework that enables you to create compact and minimal web sites that include only a few images and CSS files. jQuery Mobile is also aware of and able to respond to mobile device specific events, such as orientation change and touch events. The look and feel of jQuery Mobile based applications can be easily modified via CSS using tools such as theme-roller, thanks to it's relatively static HTML structure.

Mobile applications developed with Application Express are browser-based applications that run inside the browser on the mobile device. Therefore, these applications must have a connection in order to communicate with the Oracle Database and cannot operate in a disconnected environment. Using jQuery Mobile, these applications can run on any mobile operating system including iOS, Android, Blackberry, and Windows. Mobile devices that have HTML5 capabilities will be able to utilize all of the capabilities that can be built into the applications including HTML5 date-pickers, sub-types that display different keypads based on field definition, etc. Older devices will still render the application but with less advanced features. The major advantage of developing browser-based applications is that you only need to develop them once for the majority of mobile devices. However, one major limitation is accessing on-device features such as contact lists. This limitation can be alleviated by integrating with solutions such as PhoneGap that allow for creating hybrid solutions, which use a native application wrapper to display the web app.

Responsive Design

One of the recent user interface design principles being adopted is responsive design. Responsive design is a way to design websites so that the layout fits the available space on differently sized desktop or laptop browsers as well as tablets and smartphones. On larger screens, the user get's the full experience. On smartphones and tablets, the layout adopts itself to the size of the device's screen. This is done by having certain elements shift position, re-size or become hidden entirely. The goal is to make all essential content available in a user-friendly and pleasing way on any device. Oracle Application Express 5.0 introduces the Universal Theme which is truely responsive 'out-of-the-box' theme, without requiring the developer to design pages in any special way to be responsive. This is a large improvement over Oracle Application Express 4.2 Theme 25. Theme 25 provided the building blocks and templates that allow for achieving a responsive layout. However, it was up to the developer to use those templates and to arrange the page content in such a way that the end result is truly responsive. Also note that converting an existing application to Theme 25 requires you to review the pages of the application to ensure the appropriate template and layout are defined.

Review how Demand-Analysis have utilized Responsive Design to deliver their commercial application on multiple devices.

Responsive versus Mobile Design

The main difference between the two approaches is that responsive design allows for using a single web page with any device, while developers building mobile applications with jQuery Mobile should do so in addition to the desktop-oriented pages. Having only a single page to maintain using responsive design techniques might sound more appealing than maintaining two separate pages. However, jQuery Mobile based pages are generally very small and load a minimal amount of static content. Responsive sites on the other hand always load the full page, including content that is best suited to desktop browsers. Using CSS sprites, minified JavaScript code and other techniques may help reduce the page size. However, content such as larger headers, sidebars, rich page content, etc. would still have to be loaded, only to be selectively hidden on the client later.

The main deciding factor should be the type of site or application that is being developed and the content that is being presented. A marketing site for instance, such as a company's homes page, catalogs, libraries, and wikis are well suited for responsive design. Productivity applications, such as customer management applications, business intelligence tools, and inventory applications are good candidates for a jQuery Mobile based user interface. These types of applications require quick response time, easy to use data entry forms, and would benefit from utilizing the device's native controls. Customers who are used to quickly flipping through data using touch controls in native applications will get much the same experience with their jQuery Mobile applications, such as paginating through content using swipe, orientation change to make better use of space and context sensitive soft-keypads. Ideally of course, these type of applications would still have their desktop-orientated pages be somewhat responsive so that they work well on desktops as well as tablets.

Security

Securing the Application Express Instance

Instance administrators are responsible for setting various instance wide options to ensure the appropriate level of security for both developing and deployed applications. You should also review the Oracle Application Express Application Builder User's Guide, Understanding Administrator Security Best Practices. To further harden your environments instance administrators should review the following settings either from Instance Administration or by running the appropriate APIs:

Feature Configuration
Enable SQL and PL/SQL Access In Websheets - Disable this option when you wish to prevent Websheet users from accessing underlying database objects using the SQL tag, creating SQL reports or creating PL/SQL sections.
Enable RESTful Services - Disable this option if you do not want to allow developers to create and edit RESTFul Web Services mapped to SQL and PL/SQL in conjunction with the APEX Listener Release 2.0 and above.

Security
Disable Workspace Login - Set to Yes in test and production environments when "Runtime Only" not installed.
Allow Public File Upload - Set to No to prevent public (unauthenticated) users from uploading files.
Restrict Access by IP Address - Enter a comma-delimited list of allowable IP address ranges.
Instance Proxy - Specify the proxy server address to be used for all outbound traffic.
Require HTTPS / Outbound HTTPS - Providing HTTPS is enabled on your server, switch both to Yes to force all authenticated pages within the Application Builder to require HTTPS which encrypts network communications.
Allow RESTful Access - Disable this option if you don't want developers exposing report regions as RESTful services.
Session Timeout - Control the maximum session length and idle time as appropriate such that users must re-authenticate after a certain period. These settings can be overwritten by application-level settings.
General Login Control - Set delays after failed login attempts to prevent login bots, and specify an inbound proxy server.
Workspace Password Policy - Set various parameters to adjust how strong the passwords for all workspace users, including Application Express end users, needs to be.

Instance Settings
Self Service / Email Provisioning - Specify the amount of automation when developers request new workspaces.
Storage - Define if workspaces can utilize existing schemas, and specify tablespaces for new schemas to be encrypted.
Email - Define the email SMTP settings and set the "Use SSL/TLS" to use a secure connection for Oracle Database 11gR2 and above.
Wallet - Define the wallet, a password-protected container used to store authentication and signing credentials, used for all HTTPS requests.

Workspace Purge Settings
For large installations where there are regular requests for new service and/or limited database resources, instance administrators can define purge settings which will automatically send emails to workspace administrators whenever their workspace has been inactive for a specified period. If one of the workspace administrators does not respond to the emails saying they want the workspace preserved then it will be purged. Purging a workspace will remove old applications and release the space they utilized.

Manage Workspaces
Manage Workspace to Schema Assignment - Define the many-to-many associations between workspaces and schemas as appropriate.
Manage Developers and Users - Use this to define what schemas a specific user has access to and also whether they are a workspace administrator, developer or an end user. You can also limit developer access to specific Application Builder components and lock a specific account.
Manage Component Availability - Change access to Application Builder, SQL Workshop, and PL/SQL editing which will limit developer access across a workspace. For example, if you wanted users to be able to build database components, run SQL statements, etc but not build applications, you could define a workspace with rights to a specific schema and then configure the users as developers using this feature.

Workspace Security Settings

Workspace administrators are responsible for setting various workspace options to ensure the appropriate level of security within their workspace. From Administration > Manage Service > Set Workspace Preferences administrators can set the Account Login Control. This is specifically for Application Express end users and enables you to set the maximum login failures and the account lifetime. You can also disable access to Application Builder components or disable RESTful Services as needed.

Securing Applications

Application developers are responsible for developing secure applications. You should review the Oracle Application Express Application Builder User's Guide, Managing Application Security. Within Application Properties you can define the proxy server for the application, which will overwrite the instance value if set. You can also override instance settings for maximum session length and idle time and specify the URLs to redirect to.

Defining the appropriate authentication scheme (that is, establishing a user's identity) for an application is critical to ensure only appropriate users can log into the application. As a developer, you must determine which pages do not require authentication (also known as public pages). These pages should never contain any sensitive information. You should also define authorization schemes to easily define access to different application components. It is very important to use the appropriate authorization on sensitive pages and the navigation controls (tabs, buttons, links, etc.) used to access the page(s). You can also use authorizations on processes, validations and computations to ensure only authorized users can maintain specific data.

One of the key security measures you can adopt is Session State Protection (SSP) to limit URL tampering. Such protection can be defined for pages, page items and application items. To prevent URL tampering, all possible components should be configured with SSP. The only exceptions should be public pages and page items which are used with JavaScript such as an item used as a parent in a cascading list of values. Please note that once session state protection is set using the built-in wizards that any new pages or items defined will need to have their protection set manually.

As a developers it is important for you to also understand hardening items, especially password items. Password items should not be saved or encrypted in session state and have restricted session state protection. Where available, you should ensure that Form items have the HTML escaped. It is also advisable to restrict the enterable characters for text items to limit cross site-scripting and other injection attacks. Report regions and dynamic output should also be escaped to prevent attacks.

As a best practice, once you have completed development of your application run the Application Advisor (under Utilities). This includes many checks for conditions which could present security vulnerabilities. There are also third party tools available which extensively analyze applications for vulnerabilities. The two tools currently available are APEXSec Security Tool and APEX-SERT.

• Learn More

Performance

There are a number of factors that should be reviewed when facing performance issues with Oracle Application Express applications.

Identifying Performance Issues

The first step in reviewing slow running applications is to determine where the bottleneck is located. The performance of an Oracle Application Express application can be determined by reviewing the time it takes for the database to return a specific page request or submission. If this time is short compared to how long it takes to render the page on the user's browser then other components are likely causing the perception that the application itself is slow. You should check all of the components involved including the client machine(s), network, middle-tier, database, and disk/storage devices. With respect to the database check the SGA, CPU utilization, locks and database parameters. It is also important to determine what else is running within the database such as legacy applications, data warehouse, batch programs, and database jobs.

The majority of the time, performance issues within Application Express applications are due to developer-authored SQL and PL/SQL. You should utilize standard database performance tuning techniques to address such issues. Very seldom is the issue related to a bug with Application Express or the Oracle Database. The steps to diagnosing performance issues are to identify the time window, isolate the largest consumers of database time, identify the Application Express workspace and application, and then correlate the offending SQL with a specific location within the application. Once you have identified the slow running page(s), you should run the application in debug mode to identify the specific components consuming the most time.

For queries that have been optimized but still take more than a second processing, you should consider implementing a "progress bar" and preventing multiple page submissions. Users expect instant results and will often resubmit a page if it does not return immediately. Each page submission will instigate a new session in the database and continue until completion unless managed properly. This will often degrade performance and may lead to database locks. This is especially true with interactive reports. An alternative may be to consider using Application Express collections to hold query results. Using collections the expensive, time consuming, query is only executed once for each user rather than each time they perform pagination, filters, etc.

Activity Logs and Monitoring

Activity logs are recorded by the Application Express engine to allow administrators to review usage and performance using various reports. If a particular page is accessed extensively or a page renders slowly then these reports will often help identify the pages. Such pages are candidates for further analysis, such as running the report query in SQL Developer so that you can review the Explain Plan. Another method of determining expensive elements within a page or process is to review the Application Express Debug mode. The activity logs switch by default every 14 days, but this setting can be modified by Instance administrators. If you wish to keep the log files indefinitely it will be necessary to create a batch job to copy records from the activity log table to your own table.

There are a number of activity reports available to Workspace administrators including:

Page Views - Contains reports of page views organized by view, user, application, or application and page.

Developer Activity - Offers reports of developer activity organized by developer, day, application, application changes, and day or month.

Page View Analysis - Contains reports analyzing page views, such as top page views by application.

Sessions - Lists active sessions with the current workspace.

Login Attempts - Offers reports listing login attempts.

Environment - Contains reports of environments organized by user agent, browser, external clicks, or operating system.

Application Errors - Contains a report of application errors.

Workspace Schema Reports - Offers summaries of schema tablespace utilization and database privileges by schema and a list of all database schemas available in the current workspace.

For Instance administrators the following reports are available:

Page Views - View activity by application, user, workspace, day, or REST access.

Workspace Purge - View a dashboard summary, inactive workspaces, workspaces purged, workspaces that became active, or a workspace purge log.

Environment Reports - View a summary of used operating systems, browser types, user agent, or external sites.

Calendar Reports - View workspaces by date last used, page views by day and then by application and user, or by hour.

Service Requests - View new service requests or signup survey activity.

Logs - View the mail log, jobs log, automatic delete log, or monitor packaged application installations.

Login Attempts - View login attempts or developer last login.

Developer Activity - View application changes by developer or workspace.

Database Reporting

Application Express establishes a physical connection from the database pool as APEX_PUBLIC USER, which calls the Application Express engine. The Application Express engine utilizes SQL.DBMS_SYS_SQL to parse SQL as another user, the parsing schema. Database V$SESSION records contain useful information for each SQL executed including Application Express specific information for the client information, client identifier, and module. Such information allows you to identify the associated SQL when you generate Oracle Trace files and use TKPROF to analyze them. You can add & p_trace=YES to the end of the Application Express URL or use ALTER SESSION.

Automatic Workload Repository (AWR) reports collects performance statistics every hour, by default. Active Session History (ASH) reports are a system-wide record of database activity. Such reports can be utilized to identify resource intensive SQL statements. For PL/SQL packages, procedures and functions that in turn call other PL/SQL programs you can use PL/SQL Hierarchical Profiler in 11g (PL/SQL Profiler in 10g) which will account for execution times separately. There are also a number of Application Express views, which are a database catalog of everything related to Application Express. These views will enable you to access information from Application Express using tools such as SQL Developer, SQL*Plus or command line. If you are granted the APEX_ADMINISTRATOR_ROLE then you will be able to query across the entire instance, rather than just the workspace your schema user is associated with.

Database Configuration

There are certain database parameters that can also impact performance. In particular you should review the SHARED_POOL_SIZE and JOB_QUEUE_PROCESSES parameters to ensure they are sized correctly. Another concern is to ensure the database System Global Area (SGA) fits in real memory. An undersized SGA can dramatically hamper Application Express performance. Their needs to be sufficient memory in the Shared Pool for PL/SQL and in Buffer Cache for the Application Express metadata. If the SGA is sized correctly it should not be necessary to pin PL/SQL programs from the Application Express engine as they are accessed regularly, and should not be swapped out of memory. Given that Application Express engine resides in the database it is strongly recommended that you gather statistics on the APEX_040200 schema. Accurate statistics will allow the cost-based optimizer to develop better query plans for accessing the application metadata.

Limiting Resources

Database Resource Manager, an Oracle Database Enterprise Edition option, is exceedingly useful for maintaining an Application Express instance. Using resource manager you can limit the types of system resources (CPU_PER_CALL and LOGICAL_READS_PER_CALL) available to each user request. By setting up multiple resource profiles, with automatic switches between the profiles, as a user request exceeds a certain threshold you can reduce the CPU available to that transaction. For example you may define a default profile APEX_HIGH which can utilize 70% of CPU for 10 seconds, APEX_MEDIUM with 8% CPU for 120 seconds, APEX_LOW with 2% CPU for 1800 seconds, and OTHERS with 20% CPU. As a specific transaction exceeds 10 seconds it is switched to the APEX_MEDIUM profile which drastically reduces the CPU available. If the transaction switches to APEX_LOW and exceeds 1800 seconds then you can cancel the SQL or kill the session. This capability will ensure that one specific user or poorly written application cannot monopolize the CPU causing other users and applications to respond poorly.

Web Server

To improve performance you should place static files on the Web server. You should also enable gzip compression on the Web server so that the file size is minimized when transmitting the static files to the browser. Furthermore, enable file caching for browsers by sending expiration headers.