Si j'utilise de nombreuses variables CLOB dans la procédure stockée PL/SQL pour stocker de nombreuses chaînes de grande longueur, y a-t-il des problèmes de performances? La longueur du CLOB est-elle également variable? Y a-t-il des limitations/désavantages connus pour CLOB au lieu d'utiliser varchar2 et long?Oracle PL/SQL: Performances du type de données CLOB dans PL/SQL
Les CLOB ont une longueur variable, oui. La limite supérieure varie en fonction de la version d'Oracle utilisée et de la taille de votre bloc de base de données. Pour 11G, la limite est "valeur 4G * du paramètre DB_BLOCK_SIZE" (à partir de 11G PL/SQL Language Reference). Les valeurs VARCHAR2 sont limitées à 32767 octets en PL/SQL.
Je n'ai pas d'informations définitives sur la perforance relative de CLOB vs VARCHAR2 en PL/SQL, et un bref Google n'a pas non plus été utile. Cependant, je soupçonne fortement que VARCHAR2 fonctionne mieux que CLOB en général (pour les données qui peuvent être stockées dans l'un ou l'autre), car il est plus simple. Vous pouvez facilement mettre en place un test pour prouver ce bon ou faux en écrivant le même programme simple une fois avec VARCHAR2 et une fois avec CLOB, et en exécutant chaque 1000s fois et en comparant le temps écoulé total. L'utilitaire Runstats de Tom Kyte est d'une grande aide ici, et montre d'autres différences entre 2 approches en termes de ressources Oracle.
Mon conseil serait: si vos données dépassent 32K alors vous devez utiliser CLOB; sinon ne pas utiliser CLOB, utilisez VARCHAR2.
NB: si CLOB étaient mieux que VARCHAR2 pour toutes tailles de données de caractère, Oracle serait probablement deprecate VARCHAR2, comme ils l'ont fait avec le LONG datatype - mais ils ont pas.
Les CLOB sont sensiblement plus chers (plus lents) et plus difficiles à utiliser que VARCHAR2. Si vous utilisez inutilement CLOB au lieu de VARCHAR2, vous subissez une pénalité de performance mesurable. En fin de compte, comme indiqué précédemment, utilisez le bon type de données pour le bon travail.
1) si vous enregistrez 4000 octets ou moins dans la base de données, utilisez VARCHAR2 sinon utilisez CLOB. 2) si vous stockez 32 Ko ou moins dans PLSQL, utilisez VARCHAR2 sinon utilisez CLOB.
Tout dépend de ce dont vous avez besoin. Si vos données peuvent dépasser une limite VARCHAR2, utilisez CLOB sinon utilisez VARCHAR2. En ce qui concerne les négatifs clairs, considérons que lorsque vous travaillez avec des types de données LOB de toute nature, un LOB peut être TEMPORAIRE (jamais stocké dans une ligne réelle dans une table) ou PERMANENT (stocké dans une ligne réelle dans une table). Si vous construisez dynamiquement une CLOB dans PLSQL et passez cette CLOB à JAVA ou à un autre client externe, vous avez créé un CLOB temporaire et l'avez poussé hors du contrôle de la base de données Oracle. Cela signifie que votre code qui accepte le CLOB temporaire est maintenant responsable de la libération du CLOB quand il est fait avec. Votre code doit avoir une méthode native à son environnement que vous pouvez utiliser à cette fin. Si vous ne parvenez pas à le faire, votre espace de stockage temporaire se remplira éventuellement et votre base de données sera bloquée (arrêt du travail). Ça ne va pas tomber en panne, ça ne marche pas. Un redémarrage sera probablement nécessaire. Le problème est que de nombreux outils de développement (de nombreuses versions de Java par exemple) n'ont pas l'appel de bibliothèque nécessaire.
Bonne chance.
Les variables CLOB sont essentiellement des pointeurs, donc elles ne sont pas intrinsèquement lentes. Le problème est d'accéder au contenu du CLOB.Dans mon expérience:
dbms_lob est raisonnablement performante. Il suffit de faire cela dans une boucle: