Archives de Tag: SQL

Une promesse est une promesse

Bonjour,

Cela fait longtemps que ne n’ai pas alimenté ces lignes. J’en suis désolé. C’est donc avec pas mal de matière que je reviens vers vous. De plus, j’ai promis cette publication, dont acte. Les deux présentations ci dessous dressent le paysage de l’offre éditeurs dans les domaines concernés.

No SQL 10082015 slide

Hadoop 23102015 slide

Publicités

Poster un commentaire

Classé dans DATA, HADOOP

Terradata, mon premier SELECT

Bonjour,

Dans le cadre de ma mission actuelle, nous devons migrer des flux de données. Ils collectent actuellement des données ORACLE qui seront mises sous TERRADATA.
Il m’est personnellement impossible de me lancer vers une telle aventure sans savoir ce qu’est TERRADATA. Ainsi, le but de mon exercice est de faire mon premier SELECT sous TERRADATA.
Pour celà, je commence par m’inscrire sur le site Terradata et télécharger la VM Terrada Express.

Après le chargement de la VM sur mon poste, je m’empresse de démarrer tout celà et tombe sur une charmante fenêtre me demandant mon Login Password. Après consultation des experts les plus chevronnés (GOOGLE), il s’avère que le Login est root et le mot de passe aussi 😉
Ensuite, exploration du biniou, edécouverte de l’outil Terradata SQL Assistant correctement installé dans le répertoire Terradata Tools. YOUPI!
Quelques commandes glanées par ci par là et voilà:
https://aprevotleygonie.files.wordpress.com/2013/06/selectterradata.jpghttps://aprevotleygonie.files.wordpress.com/2013/06/selectterradata.jpg

Poster un commentaire

Classé dans DATA

Mais à quoi peuvent bien servir les normes SQL?

De temps en temps, on entend parler des normes SQL, mais dans la réalité, ces normes paraissent bien théorique voire inutiles.
Néanmoins, voici un exemple ou l’emploi des normes SQL peut permettre d’éviter des situations délicates.

Lors de l’utilisation des ETL, une pléthore de fonctions SQL peut être proposée. Ces fonctions lors de créations de mappings et de transfromations sont très utiles. Néanmoins, un grand nombre de celles-ci sont propriétaires.

En premier lieu, les fonctions propres à l’ETL, seront souvent implémentées par le serveur ETL et ne pourront en aucun cas être confiées au serveur de BDD. D’autres, seront traduites en fonctions BDD, les choix de traduction peuvent être corrects, mais aussi surprenants, voire pénalisants. Ils resteront propres à l’ETL et vous ne serez pas maitre de ceux-ci.

Ensuite, les fonctions propres à la BDD, peuvent être mises en oeuvre directement sur le serveur BDD; l’ETL soumettra une requête optimisée et efficace pour votre base. Ainsi, une commande peut récupérer des données agrégées depuis la base de données, alors que l’utilisation de fonctions d’agrégation preopres à l’ETL forcerait le rapatriment de toutes les données avant de faire l’agrégation.

Par contre, dans le cas de l’utilisation de fonctions SQL standards, un avantage supplémentaire peut être tiré. En cas de migration de base de données, l’ETL propose surement des drivers ODBC adaptés. Les fonctions utilisables sans opérations de maintenance sot les foctions propriétaire ETL et les fonctions standard SQL. Les fonctions propriétaires BDD sont à migrer.

Ainsi, le choix du type de fonction utilisées lors de l’implémentation sera déterminant pour les futures optimisations et migrations. Le plus maléable est de se conformer aux normes SQL.
Donc l’utilisation des normes peut être un atout lors de l’implémentation d’un process d’alimentation.

Poster un commentaire

Classé dans DATA, ETL

No SQL rime t-il avec No Future?

L’arrivée du terme No SQL dans le language informatique ‘hype’ a fait l’effet d’un électrochoc dans ma tête. Immaginez 15 Ans de réflexion, d’études, d’utilisation des languages SQL, SQL+, PL/SQL anéantis par le NoSQL. Ce nouveau concept mettra t-il à terre un language faisant référence depuis 1974?
Près de 40 ans d’informatique et de SGBDR réduits à néant, et rendu définitivement has been! La majorité des produits de reporting et des ETL seraient donc basés sur des principes néandertaliens, au bord de la disparition.

Fort de ces réflexions, je me suis renseigné; WIKIPEDIA est mon amie. Voici donc le lien vers la page faisant le point sur cette menace pour les métiers de la BI:
http://fr.wikipedia.org/wiki/NoSQL

Ainsi, le concept est réellement nouveau, rien encore de bien précis. Le dinosaure du reporting a encore quelques temps devant lui, mais ce concept est à surveiller de près. Une révolution est peut-être en marche.

Poster un commentaire

Classé dans DATA, ETL, RESTITUTION

Du mauvais usage du TRUNCATE

En préambule, voici la définition du TRUNCATE SQL(WIKIPEDIA):

In SQL, the TRUNCATE TABLE statement is a Data Definition Language (DDL) operation that marks the extents of a table for deallocation (empty for reuse).
The result of this operation quickly removes all data from a table, typically bypassing a number of integrity enforcing mechanisms.
It was officially introduced in the SQL:2008 standard.

The TRUNCATE TABLE mytable statement is logically (though not physically) equivalent to the DELETE FROM mytable statement (without a WHERE clause).
The following characteristics distinguish TRUNCATE TABLE from DELETE:
*In the Oracle Database, TRUNCATE is implicitly preceded and followed by a commit operation. (This may also be the case in MySQL, when using a transactional storage engine.)
*Typically, TRUNCATE TABLE quickly deletes all records in a table by deallocating the data pages used by the table. This reduces the resource overhead of logging the deletions, as well as the number of locks acquired. Records removed this way cannot be restored in a rollback operation. Two notable exceptions to this rule are the implementations found in PostgreSQL and Microsoft SQL Server, both of which allow TRUNCATE TABLE statements to be committed or rolled back transactionally.
*You cannot specify a WHERE clause in a TRUNCATE TABLE statement—it is all or nothing.
*TRUNCATE TABLE cannot be used when a foreign key references the table to be truncated, since TRUNCATE TABLE statements do not fire triggers. This could result in inconsistent data because ON DELETE/ON UPDATE triggers would not fire.
*In some database systems, TRUNCATE TABLE resets the count of an Identity column back to the identity’s seed.
*In Microsoft SQL Server 2000 and beyond in full recovery mode, every change to the database is logged, so TRUNCATE TABLE statements can be used for tables involved in log shipping. [1]

Lors de l’utilisation des ETL, la création d’un mapping peut, si on veut opérer en annule et remplace, faire appel à un mécanisme de suppression des données.
Ce mécanisme proposé est souvent nommé TRUNCATE TABLE.
Les ETL Buisness Objects Data Integrator et Informatica power Center sont tous deux concernés par ma remarque.
Ces ETL font appel à la commande SQL DELETE, et non au TRUNCATE SQL.

Voici donc la définition du DELETE SQL (WIKIPEDIA):

In the database structured query language (SQL), the DELETE statement removes one or more records from a table.
A subset may be defined for deletion using a condition, otherwise all records are removed.
Some DBMSs, like MySQL, allow to delete rows from multiple tables with one DELETE statement (this is sometimes called multi-table DELETE).

Ainsi, lors de suppression de gros volumes de données, l’ETL peut prendre un temps non négligeable, long, beaucoup trop long, voire s’approchant de l’infini.
En effet, le DELETE SQL réalise le nettoyage de la table LIGNE PAR LIGNE, alors que le TERUNCATE SQL fait la même opération, mais globalement.
Dans ce cas, il est souvent plus malin de ne pas suivre la voie tracée par l’ETL, de stopper l’alimentation, et de changer son fusil d’épaule.
Ainsi, Buisness Objects Data Integrator propose en alternative un DROP and RECREATE vraiement efficace.
Il aussi est possible de créer et appeler un code SQL faisant l’opération, que ce soit du TRUNCATE SQL ou DROP and RECREATE.

Poster un commentaire

Classé dans DATA, ETL

Tout sur mes TABLESPACES…

En chatouillant le crapeau TOAD, on peut obtenir quelques requêtes ORACLE fort intéressantes. Ainsi, lorsqu’on n’a pas le mot de passe SYSTEM et pas les droits sur les tablespaces, on peut avoir besoin de les surveiller pendant une alimentation ETL.

A l’aide du user oracle sous UNIX, il est possible de se connecter en tant que SYSDBA:

su – oracle
SET ORACLE_SID=base1
sqlplus /nolog connect / AS sysdba

Ensuite, il ne reste qu’à executer la requete sortie du fond de la mare:

SELECT t.tablespace_name « Tablespace »,  t.status « Tablespace Status »,  d.status « File Status »,  ROUND((d.max_bytes – NVL(f.sum_bytes, 0))/1024/1024) « Used MB »,  ROUND(NVL(f.sum_bytes, 0)/1024/1024) « Free MB »,  t.initial_extent « Initial Extent »,  t.next_extent « Next Extent »,  t.min_extents « Min Extents »,  t.max_extents « Max Extents »,  d.file_name « Datafile name »,  d.autoextensible
FROM
(SELECT tablespace_name, file_id, SUM(bytes) sum_bytes
FROM DBA_FREE_SPACE
GROUP BY tablespace_name, file_id) f,
(SELECT tablespace_name, file_name, MAX(bytes) max_bytes, status, autoextensible, file_id
FROM DBA_DATA_FILES
GROUP BY tablespace_name, file_name, status,autoextensible, file_id) d,
DBA_TABLESPACES t
WHERE t.tablespace_name = d.tablespace_name
AND f.tablespace_name(+) = d.tablespace_name
AND f.file_id(+) = d.file_id
GROUP BY t.tablespace_name, d.file_name, t.initial_extent,  t.next_extent, t.min_extents, t.max_extents,  t.pct_increase, t.status, d.max_bytes, f.sum_bytes, d.status,  d.autoextensible;

Poster un commentaire

Classé dans DATA, ETL