Dans le contexte d'un projet, il est fréquent de devoir migrer des données d'un environnement de production vers un environnement de test. Lorsque les tables contiennent un volume important de lignes, l'utilisation d'outils graphiques comme Navicat peut s'avérer inefficace. Par exemple, l'importation de 30 000 enregistrements a pris environ 30 minutes, ce qui a motivé la recherche d'une méthode plus performante.

Environnement technique

Procédure d'importation via SQL*Plus

Conditions préalables

Assurez-vous d'avoir un accès au serveur hébergeant la base de données Oracle, avec les privilèges administrateur ou un compte utilisateur disposant des droits nécessaires.

Transfert du fichier SQL

Uploadez le fichier SQL (par exemple, data_export.sql) sur le serveur Oracle pour permettre une exécution locale avec le client SQL*Plus.

Connexion à la base de données

Pour des raisons de sécurité, évitez de saisir les identifiants directement dans la ligne de commande, car ils pourraient être exposés via l'historique. Préférez une connexion interactive :

sqlplus
-- Entrez le nom d'utilisateur et le mot de passe quand invité.

Exécution du script

Une fois connecté, exécutez le fichier SQL avec les paramètres appropriés pour minimiser la verbosité :

-- Désactiver les retours d'information pour chaque instruction
SET FEEDBACK OFF
-- Désactiver le remplacement des variables (&)
SET DEFINE OFF
-- Spécifier le chemin vers le fichier
@/opt/app/data_export.sql
-- Valider les modifications dans la base
COMMIT;

Résultat

Cette méthode a permis d'importer un fichier contenant environ 722 000 lignes en près de 10 minutes, offrant un gain de temps considérable par rapport aux outils traditionnels.

Résolution des problèmes courants

Échec de connexion

Si une erreur de type ORA-12547 apparaît, vérifiez les permissions du binaire Oracle. Dans le répertoire d'installation, exécutez :

chmod 6751 oracle

Puis reconnectez-vous via SQL*Plus.

Données invisibles après importation

Ce problème survient généralement lorsque l'instruction COMMIT n'est pas exécutée. SQL*Plus, contrairement à certains outils graphiques, ne valide pas automatiquement les transactions.

Encodage incorrect des caractères

Pour corriger les caractères altérés (mojibake), synchronisez l'encodage client et serveur. Oracle utilise la variable d'environnement NLS_LANG pour déterminer le jeu de caractères côté client.

1. Vérifiez l'encodage serveur dans SQL*Plus : ``` SELECT parameter, value FROM v$nls_parameters WHERE parameter = 'NLS_CHARACTERSET';

2. Contrôlez la variable NLS_LANG dans le shell : ``` env | grep NLS_LANG

   
   Si elle est absente, définissez-la temporairement : ```
   export NLS_LANG=FRENCH_FRANCE.AL32UTF8
   

   Pour une configuration permanente, ajoutez-la au fichier ~/.bash_profile : ``` echo 'export NLS_LANG=FRENCH_FRANCE.AL32UTF8' >> ~/.bash_profile source ~/.bash_profile

3. Vérifiez l'encodage du fichier SQL (ex. : UTF-8, ISO-8859-1) et convertissez-le si nécessaire pour correspondre à l'encodage du serveur.

Références techniques

Interrogation des paramètres NLS

Consultez les paramètres NLS actifs de la base :

-- Tous les paramètres NLS
SELECT * FROM v$nls_parameters;
-- Paramètres depuis la base de données
SELECT * FROM nls_database_parameters;
-- Langue et jeu de caractères courants
SELECT userenv('language') FROM dual;

Jeux de caractères disponibles

SELECT value FROM v$nls_valid_values WHERE parameter = 'CHARACTERSET';

Structure de NLS_LANG

La variable NLS_LANG suit le format <Langue>_<Territoire>.<Jeu de caractères client>, où :

• Langue : détermine la langue des messages Oracle et l'affichage des dates.
• Territoire : configure le format monétaire, numérique et les conventions de calendrier.
• Jeu de caractères : spécifie l'encodage utilisé par l'application cliente.