Caractéristiques cachées dans Oracle

comme Apex fait maintenant partie de chaque base de données Oracle, ces fonctions d'utilité Apex sont utiles même si vous n'utilisez pas Apex:

SQL> declare
  2    v_array apex_application_global.vc_arr2;
  3    v_string varchar2(2000);
  4  begin
  5  
  6    -- Convert delimited string to array
  7    v_array := apex_util.string_to_table('alpha,beta,gamma,delta', ',');
  8    for i in 1..v_array.count
  9    loop
 10      dbms_output.put_line(v_array(i));
 11    end loop;
 12  
 13    -- Convert array to delimited string
 14    v_string := apex_util.table_to_string(v_array,'|');
 15    dbms_output.put_line(v_string);
 16  end;
 17  /
alpha
beta
gamma
delta
alpha|beta|gamma|delta

PL/SQL procedure successfully completed.

" les scanners complets ne sont pas toujours mauvais. Les indices ne sont pas toujours bons."

une méthode d'accès basée sur un index est moins efficace pour lire des lignes qu'un balayage complet lorsque vous la mesurez en termes de lignes accédées par unité de travail (généralement par lecture logique). Cependant, de nombreux outils interpréteront un balayage complet de la table comme un signe d'inefficacité.

prenez un exemple où vous lisez quelques centaines de factures frmo une table de facture et la recherche d'un paiement méthode dans une petite table de recherche. L'utilisation d'un index pour sonder la table de recherche pour chaque facture signifie probablement trois ou quatre io logiques par facture. Cependant, un balayage complet de la table de recherche en préparation pour une jointure de hachage à partir des données de facture ne nécessiterait probablement que quelques lectures logiques, et la jointure de hachage lui-même serait cmoplete en mémoire à presque aucun coût du tout.

cependant beaucoup d'outils regarderaient cela et verraient "full table scan", et vous diraient d'essayer d'utiliser un index. Si vous le faites, vous venez peut-être de désaxer votre code.

incidemment une dépendance excessive sur les index, comme dans l'exemple ci-dessus, provoque une augmentation du" taux de réponse du Cache tampon". C'est pourquoi le BCHR est surtout absurde comme prédicteur de l'efficacité du système.

l'indice de cardinalité n'est généralement pas documenté.

 explain plan for
 select /*+ cardinality(@inner 5000) */ *
 from   (select /*+ qb_name(inner) */ * from dual)
 /
 select * from table(dbms_xplan.display)
 /
 --------------------------------------------------------------------------
 | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
 --------------------------------------------------------------------------
 |   0 | SELECT STATEMENT  |      |  5000 | 10000 |     2   (0)| 00:00:01 |
 |   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
 --------------------------------------------------------------------------

le taux de succès du Cache tampon n'a pratiquement aucun sens en tant que prédicteur de l'efficacité du système

vous pouvez visualiser les données d'une table à partir d'une heure précédente en utilisant la requête Flashback, avec certaines limitations.

Select *
  from my_table as of timestamp(timestamp '2008-12-01 15:21:13')

11g a une toute nouvelle caractéristique placée autour de préserver les changements historiques plus fermement.

la reconstruction fréquente des indices est presque toujours une perte de temps.

wm_concat fonctionne comme le MySql group_concat, mais il n'est pas documenté.

avec données:

-car-   -maker-
Corvette Chevy
Taurus   Ford
Impala   Chevy
Aveo     Chevy

select wm_concat(car) Cars, maker from cars
group by maker

vous donne:

-Cars-                   -maker-
Corvette, Impala, Aveo   Chevy
Taurus                   Ford

Le CHEVAUCHE prédicat est sans-papiers.

http://oraclesponge.wordpress.com/2008/06/12/the-overlaps-predicate /

je viens d'apprendre pour la pseudo-colonne Ora_rowSCN. Si vous ne configurez pas votre table pour cela, ce pcolumn vous donne le bloc SCN. Cela pourrait être très utile pour l'urgence, " oh merde, je n'ai pas d'audit sur cette table et je me demande si quelqu'un a changé les données depuis hier."

mais encore mieux est si vous créez la table avec Rowdependecies sur. Cela met le SCN du dernier changement sur chaque ligne. Cela vous aidera à éviter un problème "D'édition perdue" sans devoir inclure chaque colonne dans votre requête.

IOW, lorsque vous saisissez une ligne pour modifier l'utilisateur, sélectionnez également Ora_rowscn. Ensuite, lorsque vous postez les modifications de l'utilisateur, incluez Ora_rowscn = v_rscn en plus de la clé unique dans la clause where. Si quelqu'un a touché la ligne depuis que vous l'avez saisi, aka lost edit, la mise à jour correspondra à zéro ligne puisque l'ora_rowscn aura changé.

trop cool.

si vous obtenez la valeur de PASSWORD colonne sur DBA_USERS vous pouvez sauvegarder/restaurer des mots de passe sans les connaître:

 ALTER USER xxx IDENTIFIED BY VALUES 'xxxx';

contourne le cache tampon et lit directement à partir du disque en utilisant des lectures de chemin direct.

alter session set "_serial_direct_read"=true;

provoque un checkpoint tablespace (9i) ou fast object (10g+), donc prudent sur les systèmes OLTP occupés.

plus de trucs sans papiers à http://awads.net/wp/tag/undocumented/

attention: utilisez à vos risques et périls.

Je ne sais pas si cela compte comme caché, mais j'ai été assez heureux quand j'ai vu cette façon de voir rapidement ce qui s'est passé avec une déclaration SQL que vous accordez.

SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM DUAL;

SELECT * FROM TABLE(dbms_xplan.display_cursor( NULL, NULL, 'RUNSTATS_LAST'))
;

PLAN_TABLE_OUTPUT
-----------------------------------------------------
SQL_ID  5z36y0tq909a8, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */ * FROM DUAL

Plan hash value: 272002086

---------------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
---------------------------------------------------------------------------------------------
|   1 |  TABLE ACCESS FULL| DUAL |      1 |      1 |      1 |00:00:00.02 |       3 |      2 |
---------------------------------------------------------------------------------------------


12 rows selected.

où:

• les lignes E sont des lignes estimées.
• A-Lignes lignes réelles.
• Un Temps est le temps réel.
Les tampons
• sont des tampons réels.

où le plan estimé varie de l'exécution réelle par ordres de grandeur, vous savez que vous avez des problèmes.

N'est pas une fonctionnalité cachée, mais Finegrained-access-control (FGAC), aussi connu sous le nom de row-level security, est quelque chose que j'ai utilisé dans le passé et a été impressionné par l'efficacité de sa mise en œuvre. Si vous cherchez quelque chose qui garantit que vous pouvez contrôler la granularité de la façon dont les lignes sont exposées aux utilisateurs avec des permissions différentes - indépendamment de l'application qui est utilisée pour visualiser les données (SQL*Plus ainsi que votre application web) - alors cela un bijou.

le l'indexation intégrée en texte intégral est plus largement documentée, mais se distingue toujours par sa stabilité (essayez juste d'exécuter une réindexation complète de colonnes indexées en texte intégral sur des échantillons de données similaires sur MS-SQL et Oracle et vous verrez la différence de vitesse).

avec la Clause

Instantané des tables. Également trouvé dans Oracle Lite, et extrêmement utile pour rouler votre propre mécanisme de réplication.

@Pierre

vous pouvez en fait lier une variable de type" curseur " dans TOAD, puis l'utiliser dans votre déclaration et il affichera les résultats dans la grille de résultats.

exec open :cur for select * from dual;

Q: Comment appeler un stocké avec un curseur de crapaud?

A: exemple, changez le curseur, le nom de paquet et le nom proc enregistré

declare cursor PCK_UTILS.typ_cursor;  

begin   
    PCK_UTILS.spc_get_encodedstring(  
        'U',  
        10000002,  
        null,  
        'none',  
        cursor);  
end;

Le Modèle de Clause (disponible pour Oracle 10g et plus)

WM_CONCAT pour l'agrégation de chaîne

sous-requête Scalaire de la mise en cache est l'un des plus caractéristiques surprenantes dans Oracle

-- my_function is NOT deterministic but it is cached!
select t.x, t.y, (select my_function(t.x) from dual)
from t

-- logically equivalent to this, uncached
select t.x, t.y, my_function(t.x) from t

le sous-jeu "caching" ci-dessus évalue my_function(t.x) une seule fois par valeur unique de t.x . Si vous avez de grandes partitions de la même valeur t.x , cela accélérera immensément vos requêtes, même si my_function est et non déclaré DETERMINISTIC . Même si c'était DETERMINISTIC , vous pouvez vous peut-être un commutateur de contexte SQL - > PL/SQL coûteux.

bien sûr, si my_function n'est pas une fonction déterministe, alors cela peut conduire à des résultats faux, donc soyez prudent!