Presenter: Flavio Casetta, Yocoya · June 24, 2009 Flavio Casetta - 3 summary goals db objects...

Oracle Application ExpressSchema Design Guidelines

Presenter: Flavio Casetta, Yocoya.com

about me

●Flavio Casetta●Founder of Yocoya.com●Editor of blog OracleQuirks.blogspot.com●25+ years in the IT●10+ years developing applications on Oracle●15+ years developing database applications● apex developer since htmldb 1.5

June 24, 2009 Flavio Casetta - www.yocoya.com 3

summary● goals● db objects mapping to apex components● tables, views, indexes● performance● packages vs standalone procedures● snapshots or cached reports?● synonyms and db links● Q&A


goals


goals● the goals of every apex developer should be

✔ to build fast, scalable applications that are easy to use, deploy and maintain

✔ to avoid reinventing the wheel ✔ to avoid writing the same code over and over

again● the aim of this presentation is to stress the

importance of proper database design as a strong foundation for your apex applications


db objects mapping to apex components


mapping


tables, views, indexes



● oracle provides different types of tables tailored for different situations

● standard heap tables● index organized tables aka IOTs● cluster tables● temporary tables● external tables

● oracle EE allows table partitioning



● apex's table builder wizard creates only heap tables



● SQL Developer's table builder instead comes with advanced options


tables, views, indexes● heap tables are best for data that grows over

time. The developer must properly design indexes for improving data access.

● when evaluating the indexes to be created, consider that any column(s) declared as foreign key(s) should be indexed in order to avoid contention

● if using oracle EE, consider using bitmap indexes for columns containing few distinct values on large tables with low transactional activity (like fact tables in a DW)



● IOTs are best for tables accessed by primary key and with low transactional activity.

● often reports and page items need to display a description starting from a foreign key value (which is the primary key of the IOT)

● unlike ordinary indexes, the primary key of an IOT cannot be rebuilt online


tables, views, indexes● cluster tables come in two forms:

● index clusters● hash clusters

● clusters improve I/O by storing data together

● cluster tables “pre-join” tables

● index clusters require two logical reads

● hash clusters require one logical read

● hash clusters are best for very static data

● hash clusters need precise sizing information



● external tables are useful when importing data from texts file stored in a directory on the same database server

● if deploying an application on a multi-tenant hosting server, you might have no access to local folders

● finding the right format for an external table can be challenging. Certain combinations of parameters may introduce erratic behavior



● temporary tables are good for volatile data. There are two types of GTTs and they differ in scope:

● transaction (on commit delete rows)● oracle session (on commit preserve rows)

● given the nature of apex architecture, usage of temporary tables is limited to operations that begin and end within the same transaction

● practical uses: reporting on data returned by a procedure



● views are meant to simplify the work of a developer by:● hiding complex expressions or joins that would

make a query difficult to deal with● enforcing data access rules, i.e. to limit the

results to data relevant to a certain user● decoding values to human understandable

language



● in apex, views are great for:● reporting (user defined views)● checking apex metadata (APEX_XXX)● checking db dictionary (USER_XXX,

ALL_XXX and a few V$ dynamic views)● checking certain features like oracle text

metadata and values (CTX_XXX views)


performance


performance

● tools for analyzing the performance of an apex page:● monitor activity reports● apex page debug mode● explain plan ● trace files & TKPROF


performance

● Monitor activity report● Page Views by Weighted Page Performance● Page Views by Application and Page


performance

page views by weighted page performance


performance

apex page debug mode:

● turn on debug by clicking on the “debug” link in the developer's toolbar of apex (restrictions apply)

● enter debug mode by adding YES as fifth parameter in the apex URL– http://localhost:8080/apex/f?p=12345:1:0::YES

in all cases debug mode must be enabled

http://localhost:8080/apex/f?p=12345:1:0::YES


performance

● inspect debug output and spot elapsed time anomalies


performance

● the most likely candidates for big delays in page rendering are non-optimized queries


performance

● the next step is to check what's wrong with the query by using explain plan● statistics must be up-to-date


performance

● the full table scan indicates that we are missing an index

● as the query references three columns, the most effective index will contain those three columns

● the order of the columns in the index is important

● the analysys is carried out entirely using apex features


performance

● After creating the index, the cost has decreased dramatically


performance

● this is confirmed by the time elapsed recorded in the debug output


performance

● additional considerations about the index:

● i created a compressed index, consuming fewer blocks

● the table is 100% static, so i set PCTFREE=0, saving even more blocks

● The difference in the number of blocks between the index created with default parameters and its “extreme” version is down 44%


performance

index options comparison


performance

● example of query involving a single table hash cluster containing half million rows


performance

● explain plan of the query on single table hash cluster


performance

what was the difference the day after?


performance

● when the previously mentioned techniques are not enough, tracing can be enabled

● instrumenting the code in the right way can be a life safer

● if properly designed, code instrumentation can be enabled selectively, with minimal impact when it is not in use and without collecting unnecessary information


performance

● enabling oracle tracing is easy: ➢ http://localhost:8080/apex/f?p=12345:1:0&P_TRACE=YES

● tracing makes sense only if you have access to folders on the database server (on a multi-tenant hosting service this type of action might have been restricted by the DBA)

http://localhost:8080/apex/f?p=12345:1:0&P_TRACE=YES


performance● depending on apex's configuration (either using

embedded PL/SQL gateway as Oracle XE or Apache HTTP server, trace files will be found in either in the background_dump_dest folder or in user_dump_dest

● for shared servers trace file name pattern is sid_snnn_pid.trc

● for dedicated sessions the trace file name pattern is sid_proc_pid_[tracefile_identifier].trc

● user_dump_dest and tracefile_identifier parameters don't apply for shared servers


performance

● in order to spot the relevant SQL statements quickly, you can embed comments containing custom identifiers:● select /* my_app LOV_EMP */ emp_name d, emp_id r

from employees● update order_items

/* my_app my_page_num process xyz */

set qty = :P45_QTY

where order_id = :P45_ORDER_ID


PL/SQL and apex


pl/sql

● apex make's possible to write an application without entering a single line of PL/SQL

● Functionalities that don't come off-the-shelf may require a little or a lot of custom PL/SQL

● The developer must be aware of pros and cons when adopting a method for executing PL/SQL


pl/sql● PL/SQL can be used in many places

● Processes & Computations● Validations & conditions● Post calculation, item source & initialization● Report queries & report headings● Dynamic LOVs● PL/SQL regions● Authentication functions & authorization schemes● Shortcuts● Supporting Objects


pl/sql

● Given the potential ubiquity of PL/SQL inside apex components, the developer must choose how to handle this source code:

● as anonymous blocks● as standalone procedures or functions● as packaged procedures or functions


pl/sql

● anonymous blocks are the most straightforward method to execute pl/sql

● more difficult to maintain or keep track of

● in case of an exception the source is exposed

● source code cannot be obfuscated

● editable only inside apex


pl/sql

● standalone procedures or functions can be reasonable if their number is low

● source code can be obfuscated

● editable inside apex or with other sql clients

● potentially they are reusable

● potentially they can interfere with existing objects if installed in a preexisting schema

● version management is harder than with packages


pl/sql

● packages are the way to go for large efforts

● source code can be obfuscated

● editable inside apex or with other sql clients

● packages are potentially reusable

● less prone to conflicts with existing objects if installed in a preexisting schema

● version management is easier than with standalone procedure and functions


pl/sql

● reusable procedures and functions are the best candidates for inclusion in packages:

● logging procedures● black list filtering● general purpose utilities (the swiss-knife of

each developer)● page formatting utilities like HTF/HTP for

different web languages


snapshots or cached reports?


snapshots or cache

● snapshots aka materialized views can save considerable resources

● they can be combined with cached report regions to achieve top performance

● snapshots come in handy when:

● you need to query a column resulting from a combination of multiple columns

● you need to quickly return aggregated results (sums, averages, etc.)


snapshots or cache

weighted page performance (4 wks)


snapshots or cache

weighted page performance (2 wks)


snapshots or cache

● the significant difference was achieved by removing a cached region from page zero

● caching is not supported in page zero (a fact not mentioned in the manual or help, but mentioned in the output log in page debug mode )

● without snapshots, upon expiration of the region cache, page rendering will incur in a significant increase of response time

● this occurrence can be eliminated by creating a snapshot updated in background


synonyms and db links


synonyms and db links● the main reason for using synonyms is to make

transparent to the application where the data come from

● a synonym can point to an object:

● in the same schema● in another schema● in a remote database (through a db-link)

● the type of target object can be decided during the installation for instance


synonyms and db links● developing an application basing on synonyms

can be tricky

● apex does not list public synonyms in wizards

● it can be more productive to develop using local objects that are later replaced by corresponding synonyms

● typical situations are forms on tables, tabular forms and the query builder


synonyms and db links● another typical usage for public synonyms in

apex is to make procedures callable by anonymous users from the URL

● creating a public synonym for RPC calls simplifies the URL syntax:● www.acme.com/.../user.package.procedure?arg1=...● www.acme.com/.../synonym?arg1=...

● for security reasons the synonym must also be “registered” in procedure wwv_flow_epg_include_mod_local


Q&A session

Presenter: Flavio Casetta, Yocoya · June 24, 2009 Flavio Casetta - 3 summary goals db objects...

Documents

Transcript of Presenter: Flavio Casetta, Yocoya · June 24, 2009 Flavio Casetta - 3 summary goals db objects...