7 comments — post a comment

Paris

Hello,
thank you for your blog!
I have a question about the INSERT INTO USER_SDO_GEOM_METADATA…
Do you know if the order between the “X” and “Y” is important or does Oracle read only the “X” and “Y” (or “LATITUDE” / “LONGITUDE”) to interpret the bounding ?
(If the order of the 2 dimensions is imperative, their name could be anything… “X”/”Y”, “PARALLEL”/ “MERIDIAN”, etc ?)

Thank you in advance and have a nice summertime!

smercier

Hi

The SDO_DIM_ELEMENT type is defined as:

CREAT TYPE SDO_DIM_ELEMENT AS OBJECT (
SDO_DIMNAME VARCHAR2(64),
SDO_LB NUMBER,
SDO_UB NUMBER,
SDO_TOLERANCE NUMBER);

The “SDO_DIMNAME” value is not really used by any spatial function in Oracle so you can use whatever you want. In my opinion, it’s only a “description” field to help developers. But you *MUST* follow the order of lower and upper bound and tolerance ( SDO_LB, SDO_LB, SDO_TOLERANCE ).

cheers

Paris

yes! Thank you!

Cheers

Max Demars

Bonjour, intéressant comme post.

Est-ce qu’il te serait possible d’expliquer ou justifier le choix des PARAMETERS dans le CREATE INDEX par rapport aux performances. Est-ce que le fait d’établir un extent qui couvre l’étendue de la couche permet d’améliorer les performances?
Merci, Max Demars

smercier

Bonjour Max, Merci

La spécification de ces paramètres dans le “CREATE INDEX” n’est pas obligatoire et va souvent dépendre (comme dans cet exemple) des règles corporatives édictées par le DBA de l’organisation. Les DBA d’expériences diront que c’est une *bonne pratique*; qu’ils sont fonction des spécifications techniques de l’infrastructure technologique et qu’ils ont un impact sur la performance. Personnellement,  je pense que les versions récentes d’Oracle évaluent très bien ces paramètres, mais je n’ai pas vraiment testé. Ça serait intéressant de le faire par contre

Autre bonne question qui serait intéressante à tester. À mon avis, se limiter à l’étendue de la couche n’aura aucune incidence sur la performance. Si l’étendue est vraiment trop grande, l’index occupera simplement trop d’espace sur le disque, mais n’aura pas d’impact sur les requêtes puisque l’index est justement là pour ça. Cette étendue est surtout fonction des limites possibles que les utilisateurs pourront avoir pour ajouter des données. L’index ne permettra pas d’ajouter des données à l’extérieur de cette étendue.

voilà au plaisir

Max Demars

Merci Simon pour votre réponse,
Je suis présentement en train de tester divers paramètres pour les indexes R-Tree. Selon une source sur internet: http://www.spatialdbadvisor.com/oracle_spatial_tips_tricks/51/oracle-spatial-mapping-and-map-rendering-performance-tips il est conseillé d’utiliser le PARAMETER sdo_non_leaf_tbl=TRUE pour les tables lourdes et souvent utilisées en mettant le MDNT généré lors de la création de l’index en mémoire cache. Mes tests confirment cette idée, les query sont remarqueblement plus rapides dans les applications web.

Une autre idée de cette même source est d’arrondir les coordonnées des tables à leur niveau de précision réelle pour en diminuer la taille. Cela est vrai aussi pour le niveau de tolérance qui a 0.0000000000000005 dans votre exemple semble trop précis pour rien (sous le micromètre).

smercier

Max, très juste, trop de “0″ dans la tolérance. Dans cet exemple on va modifier pour le mètre de précision. merci.

Pour sdo_non_leaf_tbl=TRUE je ne connaissais pas, mais j’ai justement un cas problématique avec un client et ce paramètre va peut-être pouvoir m’aider :-) Je n’oserais surtout pas contredire le gourou Oracle Simon Greener alors je suis convaincu que ça va aider …

Salutation

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current month ye@r day *