Index sur une colonne Date

Bonjour,
dabord bravo aux administrateurs du site qui est vraiment génial.
En tant que débutant, j'ai plusieurs questions sur les index:
. Est-il possible de créer un index sur une colonne de type Date, et si oui, est-ce que cela comporte un intéret pour accélérer
des requetes de type select .. where Date < Date1 and date > date2.
. A partir de quel nombre d'enregistrements dans la table, un index accélère -t-il substentiellement les requetes, et
quel peut être l'ordre de grandeur de l'accélération.
. Est ce que si l'on créée un Index à postériori sur une table contenant dejà des enregistrements, est-ce qu'il va s'appliquer
à ces enregistrements.
Merci pour votre aide,
Stéphane

1°) oui c'est tout à fait possible :)

2°) On peut imaginer un intérêt notable à partir de 10000 enregistrements je pense... mais j'avoue n'avoir jamais mesuré cela... d'autant que ça dépend surtout de la manière dont la table est utilisé (seule ou dans une requête complexe)

3°) on ne peut pas donner de chiffre c'est très variable... tu peux très bien passer une requête de 2h à 5 minutes comme de 5 secondes à 4 secondes. Tu peux également dégrader les perfs si tu n'as pas de chance ;)

4°) oui l'index parcourt toute la table à sa création :)

Pour la seconde question, les index sont toujours à jour de tes enregistrements. Que tu les crées avant ou après insertion.

Attention "à Jour" ne veut pas dire qu'ils sont analysés, mais juste qu'ils contiennent toujours les infos de ta table.

Merci pour vos reponses.
Spécial McM, qu'entends-tu par "analysés" ?

L'analyse d'un index ou d'une table permet à oracle en mode CHOOSE de choisir un index plutôt qu'un autre.
exemple, ta table avec 50000 lignes mais qu'avec la même date.
L'index créé (analysé à la création par oracle), oracle ne le choisira pas.. c'est pareil que faire un accès full.
maintenant tu fais un update de tes dates pour en mettre des différentes.
L'index est à jour, mais les analyses d'oracle ne sont pas faites, donc il continuera à ne pas le prendre.

En général, les tables/index de prod sont analysés tous les jours pour prendre en compte les insert/delete/update importants

un index analysé permet à Oracle d'avoir les statistiques à son sujet. C'est une étape nécessaire pour utiliser convenablement l'index en mode CBO (Cost Base Optimizer).

Tu peux rechercher DBMS_STATS ou CHOOSE dans le forum pour plus d'info ;)

j'ajouterais juste une astuce :
il faut faire attention à une chose... il est fréquent que les colonnes de type DATE soit utilisée dans les Select avec des fonctions comme to_char, trunc, etc... et ce pour leur donner un format particulier... c'est spécialement vrai pour les colonnes dont la valeur est renseignée par le système (sysdate) et donc qui contient aussi l'heure.

dans ce cas il est judicieux de réfléchir si il faut faire un index sur la colonne AVEC la fonction...
genre

Code:

---

Create index MonIndex on MaTable ( trunc(MaColonneDate) )

---

Concenant l'astuce de Yorglaa :

La commande

Code:

---

Create index MonIndex on MaTable ( trunc(MaColonneDate) )

---

fonctionne sur quelle version d'Oracle ?

Car intéressé, j'ai fait le test sur une version V8.1.7, et j'obtiens l'erreur suivante :

Code:

---

ORA-01031: insufficient privileges

---

Merci pour l'information

Ton erreur concerne plutôt un problème de droits...
tu veux faire cet index dans ton propre schéma ? ou sur une table qui n'appartient pas à ton schéma ?
auquel cas tu dois avoir le privilège "Create any index"...

Je ne pense pas que le problème vienne de là.
Ci-joint l'exemple testé :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

SQL> create table ppd1 (c1 date);   Table created.   SQL> create index ppd1_i1 on ppd1 (trunc(c1)); create index ppd1_i1 on ppd1 ( trunc(c1) ) * ERROR at line 1: ORA-01031: insufficient privileges     SQL> create index ppd1_i1 on ppd1 (c1);   Index created.

---

vu sur Metalink :

Citation:

---

Hi,
You will need QUERY_REWRITE system privilege granted to you.
Also the init.ora the parameters that need to be set are

QUERY_REWRITE_INTEGRITY=TRUSTED
QUERY_REWRITE_ENABLED=TRUE

---

Autant pour moi.

En tout cas, cette possibilité est très utile.
Jusque là, on dupliquait le champ, un premier contenant l'information complète (avec date et heure significatif), un second contenant sysématiquement l'heure à 0h00 pour être utilisé dans la clause where et donc éviter tout formattage de l'info...

Merci