Stockage de données BLOB dans des géodatabases dans Oracle

BLOB est un acronyme du secteur des systèmes de gestion de bases de données (SGBD), signifiant grand objet binaire. Les colonnes BLOB ont été implémentées il y a plusieurs années par Oracle Corporation en remplacement de la technologie LONG RAW pour le stockage des données binaires.

L'architecture du type de données BLOB est divisée en trois composants de base : colonne BLOB, segment LOB et index LOB. La colonne BLOB stocke le localisateur LOB (36 octets) et les données binaires dans la ligne si elles représentent moins de 3 965 octets et si le stockage dans la ligne n'a pas été désactivé pour la colonne.

Remarque :

Les tests réalisés par ESRI montrent que l'autorisation du stockage dans la ligne permet d'améliorer les performances ; il est donc déconseillé de désactiver ce mode de stockage.

Si les données binaires dépassent 3 964 octets, l'espace de stockage dans la ligne de la colonne BLOB n'est pas attribué et le localisateur LOB référence les données binaires stockées dans le segment LOB.

Par conséquent, une valeur stockée dans une colonne BLOB avec le stockage dans la ligne activé comporte toujours au moins 36 octets (l'espace attribué au localisateur LOB) et peut atteindre jusqu'à 4 000 octets (combinaison de l'espace attribué au localisateur LOB et de l'espace maximal pouvant être attribué aux données binaires stockées dans la ligne).

Le segment LOB est divisé en blocs. La taille des blocs doit être un multiple de la taille des blocs de données Oracle. Par exemple, si la taille de bloc de données est de 8 Ko, le segment LOB peut être créé avec une taille minimum de segment de 8 Ko. Si la longueur des données stockées dans le segment LOB est de 5 000 octets, ces dernières sont stockées dans le segment LOB car elles dépassent 3 964 octets et la taille de segment est de 8 Ko ou 8 192 octets. Dans ce cas, 3 192 octets du bloc de segment LOB restent inutilisés. Le transfert de données de LONG RAW à BLOB peut nécessiter un espace plus important, éventuellement jusqu'à 30 pour cent de plus, en raison de l'espace inutilisé dans le segment LOB. Cela est inévitable si vos données dépassent le seuil de stockage dans la ligne de la colonne BLOB, fixé à 3 964 octets.

Une taille de bloc égale à 8 Ko permet une performance E/S optimale et une perte d'espace minimale. Une taille de bloc égale à 16 Ko entraîne une perte d'espace plus importante qu'une taille de 8 Ko. Afin d'éviter la perte d'espace, il est donc conseillé de recréer la base de données dont la taille de bloc de données est actuellement de 16 Ko avec un bloc de données de 8 Ko. Si ce n'est pas possible, créez des segments LOB dans des tablespaces créés avec une taille de bloc de 8 Ko. Pour cela, vous devez attribuer un cache de tampon de 8 Ko dans le bloc SGA (Oracle System Global Area).

Les tailles de bloc de 4 Ko et 2 Ko permettent de limiter la perte d'espace mais l'augmentation en opérations E/S amène à déconseiller leur utilisation.

L'index LOB est utilisé uniquement si le localisateur LOB concerne plus de 12 blocs ; autrement, les 12 premiers blocs sont traités par le localisateur LOB.

Les trois figures ci-dessous illustrent les possibilités de stockage pour les données binaires stockées dans une colonne BLOB. Dans le premier cas, 3 000 octets de données binaires sont stockés dans une ligne, car ce volume correspond à une valeur inférieure au seuil de stockage dans la ligne, défini sur 3 965 octets. Si le stockage dans la ligne n'est pas désactivé pour la colonne BLOB, le segment et l'index LOB ne sont pas utilisés. En général, cela permet une extraction plus rapide des données BLOB en raison du nombre réduit d'opérations E/S, Oracle n'ayant besoin d'accéder ni au segment LOB ni à l'index LOB.

Données BLOB de taille inférieure à 3 965 octets stockées dans la ligne

La figure suivante illustre le deuxième cas, dans lequel les données binaires dépassent 3 964 octets (dans ce cas, les données représentent 81 920 octets) et ne peuvent pas être contenues dans la ligne. Par conséquent, le localisateur LOB référence les données binaires stockées dans le segment LOB. Puisque les données binaires n'occupent pas plus de 12 blocs dans le segment LOB, le localisateur LOB stocke les adresses correspondantes. Dans ce cas, l'index LOB n'est pas utilisé.

Données BLOB de taille supérieure à 3 964 octets stockées hors ligne. Un localisateur LOB dans la table pointe sur le segment LOB où sont stockées les données.

Dans la dernière illustration, les données binaires ont une taille telle (106 496 octets) que l'index LOB devient nécessaire. Dans ce cas, le stockage des données binaires nécessite un espace supérieur à celui disponible dans la ligne et plus de 12 blocs dans le segment LOB. Pour des données de cette taille, le localisateur LOB référence l'index LOB afin d'obtenir l'emplacement des blocs dans le segment LOB. Ce cas est extrêmement rare pour les données vectorielles et peut être évité pour les données raster.

Données BLOB stockées hors ligne nécessitant un index LOB

Configuration des paramètres DBTUNE pour le stockage de colonnes BLOB

Les paramètres de stockage de la table DBTUNE contrôlent la manière dont ArcGIS crée des tables et des index dans Oracle. Certains paramètres de stockage permettent également de déterminer le type de données utilisé lors de la création d'une table. Pour plus d'informations sur la table DBTUNE, reportez-vous à la rubrique Qu'est-ce que la table DBTUNE ? Pour des informations générales sur les paramètres de stockage DBTUNE, reportez-vous à la rubrique Que sont les mots-clés et les paramètres de configuration DBTUNE ?

Les paramètres de stockage DBTUNE d'ArcSDE, GEOMETRY_STORAGE, RASTER_STORAGE et ATTRIBUTE_BINARY déterminent le type de données Oracle utilisé pour le stockage des données ArcSDE.

Le paramètre GEOMETRY_STORAGE contrôle le stockage des données vectorielles dans une classe d'entités. Le paramètre RASTER_STORAGE contrôle le stockage de données raster dans un jeu de données raster, un catalogue d'images ou un attribut raster. Enfin, le paramètre ATTRIBUTE_BINARY contrôle le stockage de toutes les données binaires autres que vectorielles ou raster.

Pour la création de colonnes BLOB, les paramètres doivent être définis dans un mot-clé DBTUNE donné de la façon suivante :

GEOMETRY_STORAGE SDELOB
RASTER_STORAGE BLOB
ATTRIBUTE_BINARY BLOB

Pour les données raster et vectorielles, ESRI recommande les paramètres de stockage LOB suivants :

• Activez toujours le stockage dans la ligne, car la taille de la plupart des données de système d'information géographique (SIG) est inférieure au seuil de stockage dans la ligne de 3 964 octets. Ce type de stockage garantit une performance optimale.
• Activez le cache, car les données ArcSDE sont lues fréquemment.
• Au lieu d'effectuer des mises à jour sur les données BLOB, ArcSDE n'effectue que des insertions et des suppressions ; il est donc conseillé de définir le paramètre PCT_VERSION sur la valeur 0 car il est inutile de conserver des versions antérieures des données dans le segment LOB.
• Il est déconseillé d'utiliser une taille de bloc inférieure à 8 Ko. Les tailles de bloc de 2 Ko et 4 Ko augmentent le nombre d'opérations E/S car le processus de serveur Oracle doit extraire un nombre de blocs plus important. Vous remarquerez probablement qu'une taille de bloc de 8 Ko permet des pertes d'espace plus réduites qu'une taille de 16 Ko. Les tailles de bloc de 2 Ko ou 4 Ko permettent des pertes d'espace réduites, mais les tests effectués ont prouvé que la durée d'affichage de la plupart des données vectorielles et raster augmente considérablement par rapport à un stockage effectué avec une taille de segment de 8 Ko. La taille de bloc devant toujours être un multiple de la taille de bloc de données, il est préférable d'utiliser une taille de bloc de données de 8 Ko pour un stockage optimal des données SIG dans les BLOB.

Les exemples suivants montrent comment les paramètres de stockage raster DBTUNE ont été modifiés pour prendre en compte une table de blocs raster stockée avec le type de données BLOB :

RASTER_STORAGE "BLOB"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (BLOCK_DATA) STORE AS 
             (TABLESPACE RASTER_LOB_SEGMENT 
              CACHE PCTVERSION 0)" 

AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (OBJECT) STORE AS 
             (TABLESPACE RASTER 
              CACHE PCTVERSION 0)"

RASTER_STORAGE "ST_RASTER"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (BLOCK_DATA) STORE AS 
             (TABLESPACE RASTER_LOB_SEGMENT 
              CACHE PCTVERSION 0)" 

Si la taille des données de pixel du bloc raster est inférieure à 3 965 octets, les données sont stockées dans la colonne BLOCK_DATA du tablespace RASTER. Si toutefois elles dépassent ce seuil, elles sont stockées dans le segment LOB du tablespace RASTER_LOB_SEGMENT. L'index LOB est utilisé uniquement s'il y a plus de 12 morceaux de données. Il est peu probable que cela arrive pour les données ArcSDE. Considérez un segment LOB avec une taille de bloc de 8 Ko. Avant l'utilisation de l'index LOB, les données binaires ArcSDE doivent dépasser 96 Ko.

Les exemples suivants montrent comment les paramètres de stockage de données vectorielles DBTUNE ont été modifiés pour prendre en compte la table d'entités stockée avec le type de données BLOB :

GEOMETRY_STORAGE "SDELOB"

F_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE VECTOR 
             LOB (POINTS) STORE AS 
             (TABLESPACE VECTOR_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

GEOMETRY_STORAGE  "ST_GEOMETRY"

Si les données binaires de l'entité sont inférieures à 3 965 octets, elles sont stockées dans la colonne POINTS du tablespace VECTOR. Si toutefois elles dépassent ce seuil, elles sont stockées dans le segment LOB du tablespace VECTOR_LOB_SEGMENT.

ATTRIBUTE_BINARY "BLOB"

B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS 
             LOB (DOCUMENT) STORE AS 
             (TABLESPACE BIZZ_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

A_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS 
             LOB (DOCUMENT) STORE AS 
             (TABLESPACE BIZZ_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

Dans cet exemple, si la taille des données binaires de la table métier est inférieure à 3 965 octets, les données sont stockées dans la colonne BLOB de la table métier dans le tablespace BIZZTABS. Si toutefois elles dépassent ce seuil, elles sont stockées dans le segment LOB du tablespace BIZZ_LOB_SEGMENT. Dans cet exemple, la colonne BLOB est nommée DOCUMENT. Si le paramètre B_STORAGE précité de la table DBTUNE est utilisé pour la création d'une table n'ayant aucune colonne DOCUMENT, Oracle renvoie le message d'erreur suivant :

ORA-00904: "DOCUMENT": invalid identifier

Il est donc déconseillé d'ajouter au mot-clé DEFAULTS des paramètres B_STORAGE et A_STORAGE faisant référence à des colonnes BLOB spécifiques, la table métier devant contenir les colonnes correspondantes. Créez plutôt des mots-clés DBTUNE séparés et ajoutez ces paramètres de stockage aux mots-clés. Le mot-clé contenant le paramètre de stockage est référencé lors de la création de la table. Il est important de noter que les paramètres de stockage du mot-clé DEFAULTS sont utilisés s'ils ne sont pas inclus dans un mot-clé spécifique. Il est donc inutile d'ajouter un paramètre de stockage particulier dans un mot-clé si sa chaîne de configuration est identique au paramètre de stockage du mot-clé DEFAULTS. Si par exemple, à l'exception de B_STORAGE et A_STORAGE, tous les paramètres de stockage d'un nouveau mot-clé tel que ROADS ont des chaînes de configuration identiques à ceux du mot-clé DEFAULTS, il suffit de créer les paramètres B_STORAGE et A_STORAGE dans le mot-clé ROADS. S'ils ne sont pas présents dans le mot-clé ROADS, tous les autres paramètres de stockage sont lus à partir du mot-clé DEFAULTS.