| The most expensive step in the SQL preparation process is the generation of the execution plan, particularly when dealing with a query with multiple joins. When RDBMs evaluates table join orders, it must consider every possible combination of tables. For example, a six-way table join has 720 (permutations of 6, or 6 * 5 * 4 * 3 * 2 * 1 = 720) possible ways that the tables can be joined together. |
| In Oracle, optimizer_search_limit and optimizer_max_permutations parameters work together to place an upper limit on the number of permutations the optimizer will consider. But setting these values will not guarantee the best results. |
| Hints for Your SQL Statement |
| Hints are instructions that you include in your SQL statement for the optimizer. Using hints, you can specify join orders, types of access path, indexes to be used, and the intended optimization goals. You must place the hints within /*+ <hint> */, and you should place them after the SELECT key word. |
| The following statement returns the rows as soon as it finds a few: |
| SELECT /*+ FIRST_ROWS */ distinct customer_name |
| Where as the following query waits until all the rows are retrieved and sorted before returning them to the client: |
| SELECT /*+ ALL_ROWS */ distinct customer_name |
| Index Hint |
| Indexes play a very important role in SQL tuning. Indexes allow the table data to be indexed and organized, which in turn enables faster retrieval. Merely creating an index does not speed up the query execution. You must make sure that the query's execution plan uses the hinted index. In the following query, when the optimizer uses the index hint, it will be forced to use the specified index for the search on last_name: |
| SELECT /*+ index(last_name_indx) */ FROM authors WHERE last_name ='SAN%' |
| When you analyze the execution plan on this query, you will see the optimizer using this index. You can also instruct the optimizer to choose between a subset of indexes using /*+ index( indx1, indx2) */. |
| http://psoug.org/reference/hints.html |
There are two architectural models – commonly referred as SAAS Maturity models- that describe the transition of a service to what is called Multi-tenant efficient, highly scalable application. The SAAS Maturity model described by Microsoft has four distinct stages and is illustrated below. Another similar well-known model for SaaS-maturity is known as Forrester-model but adds another stage known as "Dynamic Business Apps-as-a-service". The three key Attributes of a SAAS Architecture: Configurability: Metadata used to configure the way the application behaves for customers Multi-tenant Efficiency : Maximizing the sharing of resources across tenants Scalability: Maximizing concurrency, resource efficiency SAAS Simple Maturity Model (Microsoft, 2006) SaaS Maturity Model (Forres...
Comments