Ce tutoriel peut répondre à l’erreur Oracle « ORA-39087 : nom de répertoire DATA_PUMP_DIR non valide » ou en anglais « ORA-39087: directory name DATA_PUMP_DIR is invalid » que l’on peut avoir en faisant un export de datapump avec la commande expdp ou un import avec impdp. Peut-être est-ce parce que le Datapumpdir n’a jamais été défini sur le serveur Oracle.
La solution se trouve dans la définition de la variable « Data pump dir » vers le chemin de stockage des datapumps Oracle, une information à vérifier pour résoudre l’erreur ORA39087.
Ce DATA_PUMP_DIR existe depuis Oracle 10g R2, donc également sur les version 11g R1 / R2 et 12c R1 / R2.
Voir le chemin de DATA_PUMP_DIR
Avec SQL Plus ou SQL Developer, utiliser la commande suivante pour voir le chemin actuellement renseigné du Data_pump_dir du serveur Oracle :
SELECT directory_path FROM dba_directories WHERE directory_name = ‘DATA_PUMP_DIR’;
Modifier le chemin DATA_PUMP_DIR
Pour utiliser un autre emplacement du disque dur serveur ou un lecteur réseau, il faut d’abord supprimer le raccourci Data pump dir puis le recréer et donner les droits à l’utilisateur qui va importer et exporter les bases.
DROP DIRECTORY DATA_PUMP_DIR;
CREATE DIRECTORY DATA_PUMP_DIR as ‘D:\oracle\dbdump’;
GRANT read,write ON DIRECTORY DATA_PUMP_DIR TO utilisateur;
L’import et l’export de BDD doit à nouveau être possible, du moins sans erreur ORA-39087 à cause du Data_pump_dir.
Le SGBD Oracle gère les bases de données de manière différente par rapport à SQL Server. Au lieu d’avoir un fichier par base, Oracle range les bases dans des tablespaces qui sont un espace de stockage dans lequel on enregistre une ou plusieurs bases. Mais sans interface graphique Oracle Enterprise Manager (OEM), comment voir ce qui compose un tablespace sur un serveur de BDD ?
Ce tutoriel donne la commande SQL Plus ou SQL Developer pour lister les bases de données montées sur un serveur Oracle. Toutes les versions de Oracle sont compatibles avec cette commande : 8i, 9i, 10g, 11g, 12c. Il suffira d’avoir accès au serveur Oracle, en direct sur la machine, par un accès distant (Bureau à distance Windows, VNC…) ou une connexion distante par commande ou avec l’outil Oracle SQL Developper.
Obtenir une liste des bases de données d’un serveur Oracle
1. Ouvrir une connexion SQL Developer ou SQL Plus sur le serveur Oracle avec un utilisateur disposant des droits suffisants sur le SGBD.
2. Taper la commande suivante et exécuter la requête :
SELECT sum(bytes) SUM, OWNER FROM dba_segments group by OWNER ;
3. Après quelques secondes de recherche, le résultat renvoyé liste les bases de données dans la colonne OWNER. Il s’agit donc des BDD actuellement montées sur le serveur Oracle.
Ce tutoriel explique comment réaliser un upgrade SQL Server Express (gratuit) vers une édition payante Standard ou Entreprise, même si l’Express ne limite qu’à 32 767 connexions simultanées sur le serveur de bases de données. Bien sûr, il faut disposer d’une licence adaptée et si possible d’un fichier ISO pour l’installation. Cela fonctionne également avec les téléchargements MSDN et MSDNAA pour mettre à niveau une version gratuite de test SQL Express ou Developer en serveur de production.
Ce guide de mise à niveau concerne le logiciel SQL Server dans la même version, par exemple mettre à jour un SQL Server 2016 Express version l’édition SQL Server 2016 Standard ou Enterprise. Convertir SQL Server gratuit en version sous licence payante est possible en seulement quelques minutes, il suffit de disposer du setup d’installation (ISO ou DVD) ainsi que du numéro de série relatif à l’édition achetée.
Utile pour bénéficier du Plan de maintenance (sauvegarde), pour monter un cluster ou pour importer des bases de données supérieures à 10Go (limite de SQLEXPRESS). Ce sera aussi l’occasion de vérifier les dernières mises à jour pour le SGBD, la liste des Service Pack disponibles pour SQL Server se trouve ici.
Dans le cas d’une montée de version, par exemple d’un SQL Express 2014 vers SQL 2016 Standard, il faudra passer par une installation complète de la nouvelle version, en conservant ou pas l’ancienne sur le poste.
Mettre à niveau un serveur SQL Express en édition Standard ou Entreprise
1. Sur la machine où est installé le SGBDR SQL Server, insérer le DVD d’installation ou monter le fichier ISO (par exemple la source MSDN fr_sql_server_2016_standard_with_service_pack_1_x64_dvd_9540765.iso) pour laisser faire l’autorun ou exécuter setup.exe.
2. Aller sur le menu Maintenance.
3. Cliquer sur « Mise à niveau d’édition » pour lancer l’assistant d’installation.
4. Renseigner la clé de produit (product key) pour sélectionner l’édition achetée.
5. Vérifier les informations pour conserver la ou les instance(s) SQL. Celles-ci ne seront pas renommées (donc SQLEXPRESS restera SQLEXPRESS même en SQL Server Standard) et les bases seront toujours montées et actives après mise à niveau du serveur de BDD.
6. Vérifier le récapitulatif des opération à effectuer, ici l’action est une « Edition Update » vers l’édition « Standard » avec la liste des fonctionnalités et le nom de l’instance conservée.
7. Après quelques instants, un écran récapitule les étapes de migration avec leur état (succès ou échec).
8. Le serveur SQL est maintenant sous licence, Standard ou Entreprise, et les fonctionnalités complètes sont déverrouillées pour par exemple utiliser le Plan de maintenance SQL afin de programmer des sauvegardes.
Comme tout bon programme, le SGBD Microsoft SQL Server garde un historique des actions et des erreurs rencontrées par le serveur de base de données. Ces fichiers nommés ERRORLOG peuvent être très volumineux selon les erreurs archivées. Mais pour faire du ménage ou récupérer de l’espace disque, on peut vouloir supprimer ces gros fichiers. Malheureusement, il n’est pas possible de supprimer tous les fichiers, du moins pas le fichier ERRORLOG en cours d’utilisation. SQL Server empêche de supprimer un fichier ERRORLOG qui est actuellement utilisé par le serveur de BDD.
On peut bien sûr arrêter le service MSSQLSERVER ou redémarrer l’ordinateur mais ce n’est pas une solution dans un environnement de production. Ce tutoriel explique donc comment effacer un très gros fichier ERRORLOG sans arrêt de production de SQL Server.
Remarque : les fichiers errorlogs ne sont pas là par hasard, il convient d’abord de vérifier ce qui remplit cet historique d’erreurs et de corriger les bases, requêtes ou applications qui les génèrent.
Supprimer un fichier log ERRORLOG de SQL Server
1. Aller dans le dossier d’installation de Microsoft SQL Server, par défaut un chemin du type C:\Program Files\Microsoft SQL Server
2. Ouvrir le dossier numéro de la version SQL Server, par exemple MSSQL13.MSSQLSERVER pour SQL 2016.
3. Aller ensuite dans MSSQL, Log pour voir quels fichiers pèsent plusieurs Go.
4. Si ce sont des fichiers ERRORLOG.1, ERRORLOG.2, ERRORLOG.3, ERRORLOG.4… qui sont très gros, il suffira de les supprimer (avec ou sans sauvegarde préalable).
Dans le cas où ERRORLOG « tout court » est volumineux, il ne sera possible de le supprimer depuis l’Explorateur qu’à une condition : si on arrête ou redémarre le service « SQL Server (MSSQLSERVER) » depuis les Services Windows. Autre solution, découper le fichier courant ERRORLOG pour que le serveur SQL en crée un nouveau, vide, afin que l’on puisse récupérer les Go inutilement occupés par des logs.
Découper un fichier ERRORLOG
1. Ouvrir une connexion de type Administrateur (sa) avec le logiciel Microsoft SQL Server Management Studio ou autre outil pour exécuter des requêtes sur le serveur (pas juste sur une base).
2. Copier / coller / exécuter la requête suivante pour créer un nouveau cycle de logs, c’est-à-dire une rotation pour écrire le journal dans un nouveau fichier error log :
EXEC sp_cycle_errorlog ; GO
3. Le résultat renvoyé doit être celui-ci : « Exécution de DBCC terminée. Si DBCC vous a adressé des messages d’erreur, contactez l’administrateur système. »
4. Le fichier courant ERRORLOG est passé à une numérotation (ERRORLOG.1) que l’on peut maintenant supprimer en toute sécurité, sans affecter les applications et connexions maintenues sur le serveur SQL et ses bases de données.
L’installation d’un serveur Oracle définit un nombre maximal de processus à accepter pour ne pas saturer le SGBD et on peut arriver à cette limite lorsqu’un nombre important d’utilisateurs se connecte simultanément aux BDD. Pour connaitre quelle base est concernée, quel logiciel métier ouvre trop de sessions ou quel développeur n’a pas fermé ses connexions ou a mal codé son script, voici comment lister toutes les sessions ouvertes sur les bases de données hébergées sur un serveur Oracle au moyen d’une requête à exécuter en SQLPlus ou via SQL Developer. Cette information peut aussi être disponible via la console web Oracle Enterprise Manager (OEM ou EM).
Ces requêtes sont compatibles avec les différentes versions du SGBDR Oracle : 9i, 10g, 11g, 12c (à chaque fois dans les mises à jour R1 et R2).
Liste simple des connexions à un serveur Oracle
Cette commande va simplement lister les bases ouvertes par session :
SELECT username FROM v$session
WHERE username IS NOT NULL
ORDER BY username ASC;
Résultat par SQL Plus :
Résultat par Oracle SQL Developer :
Liste détaillée des connexions à un serveur Oracle
Pour avoir plus d’informations, comme connaitre le programme qui est connecté ou quel serveur / poste de travail travaille actuellement sur une base, ce script va donner des détails sur les sessions en cours sur le SGBD Oracle.
select
substr(a.spid,1,9) pid,
substr(b.sid,1,5) sid,
substr(b.serial#,1,5) ser#,
substr(b.machine,1,15) box,
substr(b.username,1,10) username,
-- b.server,
substr(b.osuser,1,15) os_user,
substr(b.program,1,30) program
from v$session b, v$process a
where
b.paddr = a.addr
and type='USER'
order by username;
Résultat par SQL Plus :
Résultat par Oracle SQL Developer :
Ce résultat est beaucoup plus détaillé, plus facile à lire avec SQL Developper et indique les informations suivantes :
BOX : nom de la machine (hostname) qui a établi la session
USERNAME : nom de l’utilisateur connecté (user Oracle)
OS_USER : profil du système (login Windows par exemple)
PROGRAM : logiciel ou outil utilisé par la connexion
Dans les programmes, on peut retrouver sqlplus.exe (SQL Plus), Oracle SQL Developer, JDBC Thin Client (application Java)…
C’est une grande nouveauté dans le monde des SGBD, à savoir les systèmes de gestion de base de données. Depuis toujours, le système SQL Server ne s’installait que sur des environnements Windows, mais avec la version SQL Server 2017, Microsoft a rendu compatible son célèbre gestionnaire avec les distributions Linux. Une avancée considérable pour héberger des bases de données SQL Server sous Linux, en environnement web, hautement critique et où les OS Windows n’étaient pas les bienvenus.
Si l’installation graphique de SQL Server Windows est assistée mais pas forcément facile à réaliser, télécharger et installer SQL Server sur Linux est même possible en quelques lignes de commande. Ce tutoriel montre comment ajouter un serveur SQL sur la distribution Ubuntu, ici en version 16 LTS.
Installer SQL Server sur Ubuntu
1. Ouvrir un Terminal sur le serveur Ubuntu ou une connexion à distance SSH.
2. Importer les clés GPG du repository (dépôt) public de Microsoft :
5. Installer le logiciel SQL Server depuis les dépôts officiels :
sudo apt-get install -y mssql-server
6. Cette commande va définir la version à installer et préciser le mot de passe du compte sa :
sudo /opt/mssql/bin/mssql-conf setup
a. Choisir l’édition de SQL Server à installer entre :
Evaluation (trial de 180 jours)
Développeur (pour les éditeurs de logiciels informatiques)
Express (gratuit mais limitée)
Web (payant, destinée aux serveurs web)
Standard (payant, pour entreprises)
Enterprise (payant, pour grandes entreprises)
b. Choisir la langue : Français est l’option 4.
c. Définir un mot de passe administrateur système de SQL Server (compte intégré sa). Un avertissement en rouge sera affiché si le password proposé n’est pas assez complexe (8 caractères avec majuscule, minuscule, chiffre, symbole).
7. Vérifier que le service mssqlserver est bien démarré :
systemctl status mssql-server
Cette commande servira aussi dans l’administration courante de SQLServer pour Linux Ubuntu.
A noter que le port par défaut est le TCP 1433, à ouvrir sur le firewall Ubuntu si iptable ou un autre pare-feu est configuré.
Installer les outils d’administration de SQL Server Linux
Si l’installation des outils de gestion SQL Server doivent être installés sans la partie serveur du SGBD, refaire les étapes 1, 2 et 3 de la première partie de ce tutoriel pour ajouter les dépôts sur Ubuntu.
1. Ouvrir le logiciel SQL Management Studio (SSMS).
2. Dans la fenêtre de connexion, renseigner l’adresse IP ou nom DNS du serveur SQL Linux, le compte SQL « sa » ainsi que son mot de passe.
3. Notre base de données est bien présente. On peut ainsi exécuter des requêtes, gérer les droits et les utilisateurs sur le serveur SQL hébergé sur Linux Ubuntu, comme si le SGBD était installé sur un OS Windows. SQL Server version 14 correspond à l’édition 2017 (voir les versions).
Pour gérer une base de données montée sur un serveur Oracle, par exemple pour la supprimer, il est nécessaire que plus aucun utilisateur ou service ne soit connecté à cette base. Les applications métier qui travaillent avec une base Oracle ouvrent des sessions qui peuvent rester ouvertes, mêmes quand le service du logiciel est arrêté. S’il n’est pas possible de modifier la base, peut-être qu’une session est encore ouverte et il sera nécessaire de la « kill » pour manipuler la base.
Ce tutoriel explique comment fermer une session utilisateur sur une base Oracle 11g. Ce guide indique la procédure par la console web de gestion Enterprise Manager.
Fermer une session utilisateur sur Oracle 11g
1. Se connecter à la console Oracle Enterprise Manager 11g avec un identifiant qui possède des droits DBA.
2. Aller dans l’onglet Performances et cliquer en bas, dans Liens de surveillance supplémentaires, sur « Rechercher des sessions » :
Cet article a pour but de référencer toutes les versions du logiciel de gestion de bases de données Microsoft SQL Server avec à chaque fois les différents Service Pack disponibles ainsi que leurs numéros de build. Ainsi, en se connectant sur un serveur SQL distant, il sera facile de connaître la version du dernier SP installé sur le SGBD rien qu’avec son numéro de build indiqué dans la console graphique SQL Server Management Studio.
Toutes les éditions du logiciel serveur sont concernées par ces packs de mise à jour, à savoir Microsoft SQL Server Standard, Enterprise, Datacenter et même la gratuite Express.
Microsoft recommande toujours l’installation des Service Packs pour bénéficier des dernières corrections en termes de sécurité, de fonctionnalités et de stabilité. Depuis janvier 2016, l’éditeur conseille également d’installer les mises à jour Cumulative Updates dès leur disponibilité.
Remarque : Microsoft a indiqué qu’à partir de SQL Server 2017, il n’y aurait plus aucun Service Pack. Le SGBD suit désormais le « modèle de maintenance moderne » et seuls les Cumulative Update (CU) et General Distribution Release (GDR) sont diffusés. Ces correctifs sont suivis durant 5 ans après la date de sortie de la version RTM. Des extensions de support « Extended support » et « Premium assurance » peuvent allonger le cycle de vie de SQL Server jusqu’à 16 ans.
Liste des Service Pack pour Microsoft SQL Server
SQL Server 2019
SQL Server 2019 RTM « SP0 » : 15.0.2000
SQL Server 2017
SQL Server 2017 RTM « SP0 » : version 14.0.1000
SQL Server 2016
SQL Server 2016 RTM « SP0 » : version 13.0.1601
SQL Server 2016 SP1 : 13.0.4001.0
SQL Server 2016 SP2 : 13.0.5026.0
SQL Server 2014
SQL Server 2014 RTM « SP0 » : version 12.0.2000.8
SQL Server 2014 SP1 : 12.0.4100.1
SQL Server 2014 SP2 : 12.0.5000.0
SQL Server 2014 SP3 : 12.0.6024.0
SQL Server 2012
SQL Server 2012 RTM « SP0 » : version 11.0.2100.60
SQL Server 2012 SP1 : 11.0.3000.0
SQL Server 2012 SP2 : 11.0.5058.0
SQL Server 2012 SP3 : 11.0.6020.0
SQL Server 2012 SP4 : 11.0.7001.0
SQL Server 2008 R2
SQL Server 2008 R2 RTM « SP0 » : version 10.50.1600.1
SQL Server 2008 R2 SP1 : 10.50.2500.0
SQL Server 2008 R2 SP2 : 10.50.4000.0
SQL Server 2008 R2 SP3 : 10.50.6000.34
SQL Server 2008
SQL Server 2008 RTM « SP0 » : version 10.0.1600.22
Le titre « réduire la taille d’un tablespace Oracle » est légèrement erroné car il s’agit ici de réduire la taille des fichiers de données qui constituent un tablespace. Après avoir réduit la taille d’une base de données, supprimé un utilisateur Oracle ou d’avoir simplement fait du ménage dans la BDD, on voit que le tablespace Oracle est moins volumineux mais on ne récupère aucun Go d’espace disque sur le serveur. Ce tutoriel explique comment vider un tablespace pour gagner de l’espace disque dur sur la machine qui héberge le serveur SGBD. Nous allons redimensionner (resize ou purge) la taille des fichiers de données DBF qui constituent les tablespaces.
L’exemple d’utilisation est celle d’un environnement Windows Server. Cette procédure fonctionne sur les serveurs Oracle 10g, 11g et 12c.
Réduire la taille des fichiers d’un tablespace Oracle
1. Ouvrir une session SQL Plus, par exemple via un Invite de commandes cmd et en tapant : sqlplus / as sysdba
2. Taper la commande suivante, en adaptant le chemin du fichier DBF et en précisant une autre taille de redimensionnement.
alter database datafile ‘D:\oracle\oradata\orcl\USERS01.DBF’ resize 100M ;
Explication : on indique une nouvelle taille au fichier de tablespace ; le faire pour chaque fichier USERS01.DBF, 02, 03… ou pour un autre nom de fichier.
Erreur ORA-03297
Si ce message est affiché :
ERREUR Ó la ligne 1 :
ORA-03297: le fichier contient des donnÚes utilisÚes au-delÓ de la valeur RESIZE requise
C’est qu’il faut indiquer une taille supérieure de resize (par exemple 1000M au lieu de 100M) pour avoir le message « Base de données modifiée » comme dans l’exemple de ce tuto.
Malgré le paramètre AUTOEXTEND du tablespace Oracle, votre base de données ne peut s’agrandir et provoque des erreurs ? Cela peut aussi être un problème d’import qui plante, affichant un message comme celui-ci :
ORA-39171 : Le travail se heurte à une attente avec possibilité de reprise
ORA-01653 : Impossible d’étendre la table XXX de YYY dans le tablespace ZZZ
En cause, le tablespace en question (USERS ou ici ZZZ) est plein et ne peut s’étendre malgré l’autoextend activé. L’extension automatique a peut-être fonctionné jusqu’à présent mais c’est le fichier système qui est arrivé à sa valeur maximale, environ 32Go.
Agrandir un tablepace Oracle 11g par Enterprise Manager
1. Se connecter à la console web Oracle Enterprise Manager 11g avec un utilisateur type sys.
2. Aller sur l’onglet « Serveur » et cliquer sur « Tablespaces » dans la partie Stockage.
3. Cliquer sur le tablespace qu’il faut agrandir. On peut trier par « Espace alloué utilisé (%) » pour y voir plus clair.
4. Cliquer sur le bouton « Modifier » (en haut à droite).
5. Dans la partie Fichiers de données, sélectionner le bon Fichier de données (s’il y en a plusieurs) et cliquer sur « Modifier » :
6. Indiquer la nouvelle taille du fichier tablespace. Activer ou non l’extension automatique avec une valeur d’incrément. La taille maximale d’un fichier tablespace sur Oracle 11g NTFS Windows est de 32767 Mo.
7. Ne pas oublier d’appliquer les modifications pour que le changement soit pris en compte.
Ajouter un fichier à un tablespace Oracle 11g
Le tablespace pèse déjà plus que 32Go ? Suivre ce guide pour ajouter un nouveau fichier au tablespace et ainsi dépasser la limite.
1. Retourner dans l’onglet Serveur, Tablespaces et cliquer sur le tablespace en question.
2. Cliquer sur le bouton « Ajouter » (à droite).
3. Indiquer un nom pour le nouveau fichier, par exemple USERS02.DBF pour agrandir le tablespace USERS. Préciser aussi son emplacement de stockage (Répertoire du fichier), par défaut dans \APP\ADMINISTRATEUR\ORADATA\ORCL11\. Renseigner une taille de base pour ce nouveau fichier et cocher l’Extension automatique avec un Incrément, pour lui permettre d’évoluer tout seul.
4. Après avoir renseigné ces informations, cliquer sur le bouton « Continuer » et ne pas oublier d’ « Appliquer » sur l’écran suivant, rappelé par le message d’information « La modification du fichier de données ne prendra pas effet tant que vous n’aurez pas cliqué sur le bouton Appliquer. »
Il est important de garder à jour son serveur de base de données, surtout si celui-ci contient des données sensibles et est accessible depuis internet, voire est hébergé en cloud (Azure ou autre). Le SGBD Microsoft SQL Server dispose de Service Pack qui englobent toute une série de correctifs à installer en une seule opération. Mais comment savoir si son serveur SQL dispose des dernières mises à jour ? Windows Update ne s’occupe pas de ce produit tiers et les trop nombreuses informations des newsletters SQL Updates peuvent masquer une actualité importante.
Tous les deux ans environ, Microsoft dévoile une nouvelle édition de son logiciel SQL Server (2008, 2008 R2 en 2010, 2012, 2014 et actuellement 2016). Mais la firme américaine ne laisse pas son SGBD sans mise à jour durant deux ans, sans compter le reste de son cycle de vie d’une bonne dizaine d’années. Des Service Pack (SP) sortent de temps en temps pour éviter d’avoir à installer 150 KB et des Cumulative Update (CU) sortent régulièrement pour compacter une série de mises à jour récentes.
Ces Service Pack sont identiques selon l’édition de MS SQL Server : Standard, Enterprise, Datacenter et même la version gratuite Express.
Version SQL Server – Service Pack
Ces liens renvoient vers le téléchargement gratuit et officiel des Service Pack sur le site Microsoft, en langue française mais d’autres langages sont disponibles (anglais, espagnol, allemand, etc).
Remarque : Microsoft a indiqué que depuis SQL Server 2017, il n’y a plus aucun Service Pack. Le SGBD suit désormais le « modèle de maintenance moderne » et uniquement les Cumulative Update (CU) et General Distribution Release (GDR) sont diffusés. Ces correctifs sont apportés pendant 5 ans après la date de sortie de la version initiale de MSSQL Server. Des service complémentaires « Extended support » et « Premium assurance » peuvent allonger le cycle de vie de SQL Server jusqu’à 16 ans pour les entreprises et organisations qui paieront pour ce service.
A chaque installation de Service Pack ou de Cumulative Update, le numéro de version SQL est modifié :
Voir cette page pour connaitre à quel Service Pack correspond un numéro de version SQL Server. Microsoft centralise les liens vers les dernières mises à jour Service Pack (SP) et Cumulative Update (CU) sur cette page TechNet. Ainsi, c’est l’assurance de toujours avoir la dernière mise à niveau des correctifs disponibles en un seul coup d’oeil.
Les montées en version (par exemple SQL Server 2008 R2 vers 2016) peuvent se faire moyennant l’achat d’une nouvelle licence dans la dernière version disponible. Les abonnés MSDN peuvent en profiter selon leurs droits et les entreprises ayant souscrit à une Software Assurance peuvent également en bénéficier sans surcoût, si ce n’est la main d’oeuvre et peut-être l’ajout de ressources matérielles dans le serveur.
Si la console Enterprise Manager de Oracle 11g est plutôt explicite à ce sujet, l’EM version Oracle 12c n’affiche pas les mêmes informations visuelles de l’utilisation des tablespaces. Ces espaces alloués peuvent être remplis ou vides, selon les bases montées à l’intérieur. Il est toujours intéressant de savoir où en sont les espaces de stockage, pour savoir s’il faut en agrandir un tablespace, mieux gérer son espace alloué ou en créer un nouveau.
Oracle 11g ou 12c, voire 10g, on peut voir l’utilisation des tablespaces grâce à une requête SQL Plus pour éviter l’utilisation de la console graphique Enterprise Manager, plus visuelle mais pas présente sur toutes les versions du SGBD Oracle.
Voir l’utilisation des tablespaces sous Oracle 11g (EM)
1. Ouvrir la console Enterprise Manager du serveur Oracle 11g, par exemple https://srvoracle11g:1158/em
2. Se connecter en compte sys ou équivalent.
3. Aller à l’onglet Serveur, Tablespaces (dans le groupe Stockage) :
4. Un tableau résume les tablespaces avec la taille pré-allouée, l’espace utilisé et l’espace encore libre dans le fichier alloué. Dans cet exemple, le tablespace USERS est plein à 92,2% mais il reste presque 18Go de libre sur les 228Go alloués.
Requête pour voir l’utilisation des tablespaces sous Oracle
1. La console SQL Plus permet de voir la même information, peu importe la version du serveur Oracle (10g, 11g, 12c). Se connecter avec un compte sys ou équivalent (connect).
2. Copier / coller la requête suivante :
select T1.TABLESPACE_NAME,
T1.BYTES / 1024 / 1024 as "bytes_used (Mb)",
T2.BYTES / 1024 / 1024 as "bytes_free (Mb)",
T2.largest /1024 /1024 as "largest (Mb)",
round(((T1.BYTES-T2.BYTES)/T1.BYTES)*100,2) percent_used
from
(
select TABLESPACE_NAME,
sum(BYTES) BYTES
from dba_data_files
group by TABLESPACE_NAME
)
T1,
(
select TABLESPACE_NAME,
sum(BYTES) BYTES ,
max(BYTES) largest
from dba_free_space
group by TABLESPACE_NAME
)
T2
where T1.TABLESPACE_NAME=T2.TABLESPACE_NAME
order by ((T1.BYTES-T2.BYTES)/T1.BYTES) desc ;
Cette longue requête est aussi disponible dans ce fichier texte pour éviter les problèmes de copier/coller.
3. Le résultat s’affiche sous forme d’un tableau. On retrouve les quasi 18Go de libre sur 228Go de notre exemple précédent en console Enterprise Manager.
ORA-56935: les travaux Data Pump existants utilisent une version différente du fichier de données de fuseau horaire. En voilà une drôle d’erreur renvoyée par la console SQL Plus d’un serveur Oracle.
Dans un exemple de migration d’une base de données entre un serveur Oracle 11g et un 12c, l’erreur ORA56935 est apparue, empêchant ainsi l’import de la base au format datapump. Cela peut aussi arriver entre Oracle 10g et 11g, de 10 à 12, etc.
Cela parle d’un problème de fuseau horaire alors que les deux serveurs sont dans le même réseau et avec le même serveur de temps NTP. Il s’agit d’une erreur connue des DBA Oracle et voici la solution pour réussir à importer la base de données récalcitrante. L’opération s’applique au serveur complet et pas juste au tablespace en question.
Erreur lors d’un import Oracle
ORA-39006 : erreur interne
ORA-39065 : exception de processus maître inattendue dans DISPATCH
ORA-56935 : les travaux Data Pump existants utilisent une version différente du fichier de données de fuseau horaire
ORA-39097 : Le travail Data Pump a détecté une erreur inattendue -56935
Solution officielle Oracle
Sur le site du support Oracle référençant les Database Error Messages (lien) :
ORA-56935 : existing datapump jobs are using a different version of time zone data file Cause: An attempt was made from a datapump job to request a different version of time zone data file from the one used by existing datapump jobs. Action: Wait until existing datapump jobs unload the secondary time zone data file.
Solution efficace
La manipulation se fait avec une simple ligne de commande, au niveau du serveur SGBDR, pas d’un tablespace.
1. Ouvrir une console SQLPlus sur le serveur Oracle 12c (celui qui reçoit l’import de BDD).
2. Se connecter avec un compte sys ou équivalent.
3. Entrer et valider les commandes suivantes :
ALTER SESSION SET EVENTS ‘30090 TRACE NAME CONTEXT FOREVER, LEVEL 32’;
exec dbms_dst.unload_secondary;
4. On peut vérifier la nouvelle valeur du fuseau horaire / timezone par cette commande (via Oracle SQL Developer par exemple) :
SELECT PROPERTY_NAME, SUBSTR (property_value, 1, 30) value FROM DATABASE_PROPERTIES WHERE PROPERTY_NAME LIKE ‘DST_%’ ORDER BY PROPERTY_NAME;
5. Le résultat doit être celui-ci :
DST_PRIMARY_TT_VERSION 26
DST_SECONDARY_TT_VERSION 0
DST_UPGRADE_STATE NONE
Si le résultat est différent, il faudra peut-être appliquer une seconde fois les deux commandes de l’étape 3.
5. Le serveur peut maintenant accepter un import de datapump sans provoquer d’erreur de fuseau horaire ORA-56935.
Console Enterprise Manager inaccessible, vue rapide ou en prévision d’un export en texte, il est possible d’accéder aux utilisateurs Oracle en dehors de l’interface web de gestion EM. Ce tutoriel explique comment lister les utilisateurs Oracle à partir d’une simple ligne de commande. Cette commande se lance via la console sqlplus livrée avec le serveur Oracle.
Cette commande fonctionne avec Oracle 11g et Oracle 12c.
Afficher la liste des utilisateurs Oracle en une commande SQLPlus
1. Ouvrir un Invite de commandes (cmd.exe) sur le serveur Oracle.
2. Ouvrir une session SQLPlus : sqlplus /nolog
3. Se connecter à l’instance Oracle : connect
Saisir les identifiants d’un compte Oracle (pas forcément sysdba mais qui pourra lister les comptes)
4. Taper la commande suivante : select * from all_users ;
5. S’affiche ainsi la liste de tous les utilisateurs du serveur Oracle (USERNAME) avec leur USER_ID et la date de création du compte.
Erreur SP2-0640 : Non connecté
Si l’erreur « SP2-0640 : Non connecté » s’affiche, cela signifie que l’étape de connexion « connect » n’as pas été effectuée.
Supprimer des utilisateurs ainsi que leurs propriétés associées est utile pour faire du ménage dans son serveur SGBD Oracle, pour supprimer des bases ou pour récupérer de l’espace disque. Il s’agit d’une opération classique de maintenance et qui ne nécessite pas de connaissances pointues en administration de bases de données.
Il existe deux manières d’annuler un user : on peut simplement supprimer le compte utilisateur ou supprimer le compte ainsi que ses objets (tablespace, etc). Dans ce cas, on ajoute l’attribut CASCADE.
Attention à ne pas supprimer un compte sys ou system au risque de planter le serveur Oracle.
La procédure est à réaliser avec un compte sys ou qui dispose au moins du privilège DROP USER.
Supprimer un utilisateur Oracle 12c avec la console Enterprise Manager
1. Se connecter à la console EM (avec un login autorisé à Drop user) : https://serveuroracle:5500/em
2. Aller à l’onglet Sécurité, Utilisateurs.
3. Sélectionner l’utilisateur à supprimer.
4. Cliquer sur le bouton « Supprimer un utilisateur » :
5. Laisser cochée la ligne « Cascade » pour supprimer les objets de cet utilisateur et valider par OK.
Supprimer un utilisateur en ligne de commande
1. Ouvrir la console SQL Plus (ou un cmd avec sqlplus)
2. Se connecter au serveur avec un compte qui dispose du droit Drop user : connect
ORA-01940 : cannot drop a user that is currently connected
ORA-06512
Si des connexions fantômes sont encore actives sur le serveur ou qu’une autre erreur empêche la suppression de l’utilisateur, suivre cette méthode plus radicale. Concrètement, on arrête le serveur pour le relancer en mode restrictif (seuls les DBA pourront s’y connecter) avant de le repasser en mode normal. Prévoir quelques minutes pour cette opération.
En cas d’un nombre trop élevé de tentatives échouées de connexions, ou pour d’autres raisons, un compte utilisateur Oracle peut être bloqué. Celui-ci est locked et rend donc son utilisation impossible, que ce soit par une application qui utilise le système SGBD ou par la console de gestion Enterprise Manager.
L’erreur ORA-28000 affichée par Oracle 12c EM lors d’une tentative de connexion avec l’utilisateur locké :
Echec de la connexion avec une erreur inattendue
ORA-28000 : the account is locked
Ce tutoriel explique comment réactiver un compte utilisateur Oracle verrouillé (locked).
Réactiver un compte utilisateur verrouillé dans Oracle 12c
1. Se connecter à Oracle Enterprise Manager avec un compte sys (system, sys, sysman ou un autre compte admin).
2. Aller sur l’onglet Securité, Utilisateurs (Security, Users en anglais).
3. Cliquer sur la ligne du compte utilisateur verrouillé : s’aider du tri par la colonne « Statut du compte » ou par le champ de recherche. Un icône de cadenas confirme ce verrou.
4. Aller dans le menu Actions, Modifier le compte (ou Actions, Alter Account).
5. Décocher la ligne « Compte verrouillé » (Account Locked).
Commande équivalente en SQL :
alter user "OUTLN" account unlock container=ALL;
6. Le compte utilisateur est déverrouillé et sera à nouveau accessible par l’application, par la console web Enterprise Manager ou via un logiciel comme l’environnement de développement intégré (EDI) Oracle SQL Developer.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.