My Memory Dump

Aller au contenu | Aller au menu | Aller à la recherche

mardi 16 décembre 2014

Commandes SQL Server utiles


-- Espace disque disponible sur le serveur SQL :


EXEC xp_fixeddrives
GO


-- Exécuter une commande système sur le serveur SQL Server, à distance, via Management Studio :


EXEC sp_configure 'show advanced options', 1
GO

RECONFIGURE
GO

EXEC sp_configure 'xp_cmdshell', 1
GO

RECONFIGURE
GO

-- Espace disque total et disponible du serveur
EXEC master.dbo.xp_cmdshell 'wmic logicaldisk get size,freespace,caption'
GO


-- Forcer un changement de fichier log sans redémarrer :


EXEC sp_cycle_errorlog
GO

dimanche 23 novembre 2014

Performance Oracle, Optimiseur et CPU

Dans mon billet sur le paramètre "session_cached_cursor" (voir plus bas) je parlais de problèmes de temps de réponse Oracle liés au temps mis par l'optimiseur pour calculer le plan d'exécution des requêtes. Phénomène aggravé par le fait que l'application concernée utilisait des littéraux au lieu de variable "bind" donnant encore plus de travail à l'optimiseur.

Mon serveur Oracle est virtualisé et l'ajout de vCPU ne m'avait pas permis d'améliorer les choses. De toute façon les lenteurs de l'optimiseur étaient ressenties même avec un seul utilisateur connecté. Je ne suis pas sûr, mais je pense que l'optimiseur travail par "thread", un thread par session par exemple et je pense qu'un thread ne peut exploiter qu'un cœur de processeur. Donc l'ajout de vCPU ne change rien.

Suite à mon billet sur la compilation Visual Studio 2010 et l'intérêt de disposer de processeur avec "mode turbo" (voir plus bas) j'ai déplacé mon serveur Oracle sur un Hyper-v disposant de tels processeurs.

Bilan : Nette amélioration des temps de réponse Oracle et pourtant je ne suis passé que de 2.4 GHz à 2,8 GHz en mode turbo. J'attends avec impatience l'achat du prochain serveur Hyper-v pour lequel la fréquence CPU et le mode turbo seront privilégiés.

samedi 12 juillet 2014

sessions_cached_cursor

Cela faisait quelque temps que je cherchais à améliorer les temps de réponse d'une application connectée à une base Oracle 11g R2.

L'advisor d'Oracle Enterprise Manager indiquait que l'application utilisait des littéraux dans ses requêtes et que l'usage de variables "bind" à la place de ces littéraux aurait pu diminuer la consommation de CPU et le temps d'exécution des requêtes. Seulement je n'avait pas accès au code de l'application en question et donc je ne pouvais rien y changer.

Pourquoi les variables bind permettent de gagner du temps ?

Parce qu'Oracle considère qu'une requête qui lui est soumise deux fois de suite avec des valeurs (littéraux) différentes revient à deux requêtes différentes. Il va donc passer du temps d'analyse (parsing) sur la deuxième, pour déterminer le plan d'exécution, alors qu'il a déjà fait le travail pour la première. De plus il va stocker en mémoire deux plans d'exécution très probablement identiques.
Avec des variables bind, la requête ne serait analysée qu'une fois et il n'y aurait qu'un seul plan d'exécution.

J'ai tenté d'utiliser le paramètre cursor_sharing en lui donnant la valeur "force", cela permet justement de forcer le remplacement des littéraux par des variables, malheureusement cela a provoqué des erreurs dans l'application et j'ai du revenir en arrière (cursor_sharing=exact).

Je pensais être bloqué jusqu'à ce qu'on me parle du paramètre "sessions_cached_cursor". Ce paramètre indique combien de requête Oracle conserve en mémoire par session. Les informations conservées en mémoire sont le texte de la requête et le plan d'exécution, cela ne concerne pas les données. Son augmentation (valeur par défaut 50, passé à 1000) à nettement améliorer les temps de réponse de l'application. Je n'ai pas noté d'augmentation significative de la consommation de sga ou de pga.

Remarque : Cette modification n'améliore les temps d’exécution des requêtes qu'à partir de la quatrième exécution, au lancement, l'application reste donc lente puis au fur et à mesure de l'utilisation, les temps s'améliorent. Donc c'est valable pour une application utilisée toute la journée. Pour une utilisation ponctuelle de quelques minutes cela risque d'être inutile.

Pour effectuer la modification :

alter system set sessions_cached_cursor=1000 scope=spfile;

Puis redémarrage de l'instance.

jeudi 26 juin 2014

ORA-39083

Lorsqu'on importe, via impdp, deux fois le même schéma dans la même instance Oracle (par exemple pour avoir un schéma de test et un de prod), on peut être confronté à cette erreur :

ORA-39083: Echec de la création du type d'objet TYPE:"MONSCHEMA"."T_VARCHAR2_TAB" avec erreur :
ORA-02304: constante d'identificateur d'objet non valide
SQL en échec :
CREATE EDITIONABLE TYPE "MONSCHEMA"."T_VARCHAR2_TAB" OID 'FCAF535E494D5154E043110114AC9DC7' AS TABLE OF VARCHAR2(4000);

Impdp tente de recréer le même OID et il échoue. Cela entraine généralement des erreurs de compilation et l'import ce termine avec des avertissements.

Solution : ajouter le paramètre transform=OID:n à la fin de la commande d'import. Cela permet à oracle de générer un nouvel OID. Valable à partir de la version 10g (comme l'import datapump).