Note utilisateur: 0 / 5

Etoiles inactivesEtoiles inactivesEtoiles inactivesEtoiles inactivesEtoiles inactives

Note utilisateur: 0 / 5

Etoiles inactivesEtoiles inactivesEtoiles inactivesEtoiles inactivesEtoiles inactives

La console oracle OEM fonctionne (emctl status dbconsole sur le serveur de base de données nous dit running) mais impossible d'avoir la mire de login depuis un client avec IE. Internet Explorer semble bloquer le site de la console malgré l'avoir passé en site de confiance et malgré avoir désactivé la vérification du certificat serveur rien n'y fait ?

Sur votre poste client windows, ouvrez une fenêtre de commande en tant qu'administrateur et essayez ceci :

certutil -setreg chain\EnableWeakSignatureFlags 8 

Cela permet d'accépter les site dont les certificats ne répondent pas aux critères de sécurité windows et la console oracle 11g en fait partie. Microsoft a publié un avis de sécurité indiquant que l'utilisation des certificats RSA dont la longueur de clés est inférieure à 1024 bits sera bloquée : http://support.microsoft.com/kb/2661254/fr

 

 

 

 

 

 

Commentaire (0) Clics: 2859

Note utilisateur: 5 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles actives

source: Oracle® Database - SQL Language Reference - 11g Release 1 (11.1) - B28286-05
source: Oracle® Database - Administrator's Guide - 11g Release 1 (11.1) - B28310-04

Lorsque que l’on utilise une instruction DML (insert/update/delete/merge) via une sous requête, plutôt que d’avoir une erreur puis un rollback il est possible de gérer certaines erreurs via une table de journalisation d’erreur :

  • En fixant la limite du nombre de lignes en erreur ou en positionnant cette limite à UNLIMITED
  • En utilisant la fonctionnalité de logging des erreurs DML.

 

Voyons comment utiliser cette fonctionnalité :

Les erreurs gérées :

  • Valeurs trop large pour la colonne
  • Violations de contrainte (NOT NULL, unique, referential, et check constraints)
  • Erreurs levées pendant l’exécution d’un trigger
  • Erreurs résultant d’une conversion de type entre la colonne cible et la sous-requête
  • Erreur de mapping de Partition
  • Certaines erreurs sur des opérations de MERGE (ORA-30926: Unable to get a stable set of rows for MERGE operation.)

 

Les erreurs non gérées :

Certaines erreurs ne sont pas enregistrées par la gestion intégrée des erreurs et entrainent l’arrêt de l’opération de DML et son rollback

  • Violation de contraintes différées.
  • Une opération d’INSERT, d’UPDATE ou de MERGE en direct-path qui lève une violation de contrainte unique ou d’index unique.
  • Il n’est pas possible de tracer les erreurs dans un table de trace pour les colonnes de type LONG, LOB, ou object . Toutefois, la table en cible de l’opération DML peut contenir ce type de colonne :

     

    • Si vous créez ou modifiez la table de journalisation d'erreur correspondant afin qu'elle contienne une colonne d'un type non pris en charge, et si le nom de la colonne correspond à une colonne non pris en charge dans la table cible de l'opération DML, l'instruction DML échoue au moment du parse.
    • Si la table de journalisation d'erreur ne contient pas tous les types de colonnes non pris en charge, alors toutes les erreurs DML sont enregistrés jusqu'à ce que la limite d'erreurs soit atteinte.
    • Pour les lignes sur lesquelles des erreurs se produisent, les valeurs correspondantes au colonnes dans la table de journalisation des erreurs sont enregistrées avec les informations de commande.

 

Commentaire (0) Clics: 2225

Note utilisateur: 5 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles actives

Suite à un audit de performance chez une entreprise qui cherchait à améliorer les performances MSSQL Server (SSDE 2008 SE 64 bits sur W2K8R2) pour son application CRM (SugarCRM), j'ai constaté un comportement au premier abord étrange sur la gestion des chaînes unicode sur le SGBD de microsoft...
Le consultant spécialiste de l'application (SugarCRM) me fit remarqué que des requêtes très simples à priori n'avaient pas la performance attendue.
En étudiant de près une requête type j'ai constaté un effet étonnant concernant l'utilisation de filtres avec une chaîne unicode : colonne1=N'machaine' alors que la colonne que l'on cherche à filtrer est de type varchar (et non nvarchar).

La requête qui m'a posé problème était une requête très simple d'une durée de 200ms environ. Pas de problème de performance avec 200ms par requête me direz vous, sauf que cette requête était lancée plusieurs dixaines de fois pour certains écrans.

Voici la requête :

 

SELECT 
acc.id, acc.name, con_reports_to.first_name, con_reports_to.last_name
FROM
contacts
LEFT JOIN accounts_contacts a_c ON a_c.contact_id = N'1A9C0C58A81C4195B854739635E435D5' AND a_c.deleted=0
LEFT JOIN accounts acc ON a_c.account_id = acc.id AND acc.deleted=0
LEFT JOIN contacts con_reports_to ON con_reports_to.id = contacts.reports_to_id
WHERE
contacts.id = N'1A9C0C58A81C4195B854739635E435D5'

 

On notera sur cette requête les prédicats=N'1A9C0C58A81C4195B854739635E435D5'. Le N qui préfixe la chaîne indique au moteur relationnel de sql server qu'il s'agit d'une chaîne de caractère unicode. Or les colonnes sur lesquelles portent les filtres ne sont pas en nvarchar mais en varchar.En observant les statistiques et le plan d'éxécution on observe ceci :

Commentaire (0) Clics: 4779

Note utilisateur: 5 / 5

Etoiles activesEtoiles activesEtoiles activesEtoiles activesEtoiles actives

La version 11 de SQL Server (aka MSSQL 2012 ou Denali) introduit un nouveau type d'index permettant de stocker les données en mode colonnes.

Les columnstore index, particulièrement adaptés aux requêtes décisionelles accélèrent ces requêtes pour plusieurs raisons :

  • Les données stockées sont compressées assez fortement, ce qui entraîne moins d'IOs physiques et moins de consommation mémoire.
  • Les données stockées en colonnes permettent un balayage limité des données en fonction des colonnes demandées dans la requête.
Il y a cependant quelques restrictions liées à ce type d'index :
  • Il n'est pas possible d'écrire sur une table ayant un index en colonne. Il est cependant possible de contourner ce type de limitation avec le partitionnement : on écrit dans un table intermdiaire sans index, on créer l'index sur la table intermédiaire, on switch la table intermédiaire avec une partition de la table cible.
  • Il ne peut il y avoir qu'un seul index de type columnstore par table. Vu que c'est un stockage en mode colonne, on aura donc tendance à avoir un index incluant toutes les colonnes utiles de la table.
  • Au moment de la création de l'index, il y a une forte demande de mémoire. La mémoire demander est exterieure au buffer pool (donc en plus du max memory/target)
Voyons comment créer ce type d'index et comparons le à un index classique.
Avec SSMS on voit l'apparition de nouveau type d'index dont le Columnstore Index :

 

Création d'un nouvel index columnstore via SSMS

 

Commentaire (0) Clics: 3312

Sous-catégories

Des tutoriaux et cours gratuits sur Oracle

Articles traitant de l'intégration de données

Tutoriaux sur Unix et les shells scripts