BI experience

2 mars 2018
par maryam khiali
0 Commentaires

C’est quoi le In Memory OLTP ?

Sur les deux articles précédents, nous avons décrit les options présentes ou pas aux niveaux des différentes versions et éditions d’SQL server.
Encore faut-il comprendre à quoi servent ces options afin de savoir si dans notre cas client elles pourraient nous être indispensables…

Je vous propose lors des articles à venir de décrire ces options en restant sur un angle BI pour une lecture plus facile et orientée.

Commençons donc par l’option « In Memory OLTP ». Cette option apporte performance pour les traitements transactionnels en :
- supprimant des verrous entre les transactions exécutées simultanément.
- optimisant en mémoire, les algorithmes de stockage des données, les accès et les traitements des données.

Les objets qui permettent de bénéficier de ces performances sont :

  • Les « Memory optimized tables » : ces types de tables sont utilisées par exemple
    • pour les « table-valued parameters » : permettant de faire du chargement en bulk de plusieurs lignes de données en une fois.
    • dans les procédures stockées, pour les jeux de données intermédiaires stockés dans des tables de type de « Memory optimized tables » . Ces dernières hériteront des avantages des « non durable memory optimized tables  » : accès efficace aux données et absence d’E/S

Ce type d’objet ne réduit pas l’utilisation du processeur.
(si la plupart des requêtes effectuent des opérations d’agrégation sur de grandes plages de données  : utiliser plutôt des index columnstore)

  • Les « non durable tables memory optimized tables » : Le stockage principale de ces tables est la mémoire principale. Les modifications apportées à ces tables n’entraînent aucune E/S
  • Les « natively compiled T-SQL modules » (procédures stockées, déclencheurs et fonctions scalaires ) permettent d’accélérer encore plus l’exécution d’une transaction individuelle en réduisant les cycles processeur requis pour traiter les opérations.

Les scénarios BI qui peuvent nous intéresser :

Use case 1 : Remplacer certains objets standards de la tempdb :
- les « tables temporaires » (#temp) par les « Non durable tables memory optimized tables » qui réduisent généralement l’utilisation du processeur
- ou encore les « variables de table » par les « table-valued parameters » qui suppriment complètement les E/S de journal.

Use case 2 : au niveau de l’ETL

- Pour charger et mettre à jour d’importants volumes de données provenant de nombreuses sources différentes : utiliser des « non durable tables memory optimized tables » pour la mise en lots des données. Elles suppriment complètement les E/S et optimisent l’efficacité de l’accès aux données.

-Pour accélérer les transformations sur la table de mise en lots : utiliser des « natively compiled T-SQL modules« . De plus pour toujours plus de performance, il sera possible de paralléliser ces transformations.

J’espère que ce point est un peu plus clair…Dites moi ce que vous en pensez…Si vous avez déjà utilisés ces options…

2 mars 2018
par maryam khiali
0 Commentaires

Comparaison des versions d’SQL server

Avec la sortie d’SQL server 2017, je me suis dit qu’il fallait que je jette un œil aux nouvelles options. Quand on est chez un client final, on a tendance à être phagocyté par les problématiques métiers et les technologies présentes chez le client. Il faut donc faire un effort de veille technologique qui est peut être plus évident en société de service.

Voici dans cet article une comparaison des différentes versions d’SQL server. On constate vraiment les avancés technologiques faites en 10 ans. Le consultant BI se doit d’être un couteau suisse.

J’ai retranscrit sur Excel les options car je trouvais ça plus lisible. Voici ma source de données.

 

7 juin 2017
par maryam khiali
0 Commentaires

Femme ingénieure

En me baladant sur le net, je suis tombée sur ce site que j’ai trouvé génial : femme-ingenieure.fr.
Quand j’étais en école d’ingénieur, j’aurai vraiment aimé avoir accès à ce genre de site. Nous étions 15 filles sur une promotion de 300 personnes…
Il est vrai qu’être une femme dans le milieu du numérique n’est pas toujours facile à bien des égards que ce soit en milieu scolaire ou même en milieu profesionnel.
En parcourant ce site, j’ai constaté que les esprits changent et ça fait du bien!
Bonne lecture!

6 juin 2017
par maryam khiali
0 Commentaires

Reportservertempdb grossit de manière significative

N’ayant pas de serveurs surdimensionnés à ma disposition, le moindre gigaoctet est précieux.
En monitorant les serveurs j’ai pu constater que la table « Segment » de la base « Reportservertempdb » avait pris un volume de plus de 50Go.

En creusant le sujet, j’ai pu lire sur les forums que cette taille qui augmente pouvait avoir 4 causes:
- Cause 1 : le nombre de snapshot stockés par rapport
- Cause 2 : des rapports qui mettent plus de 10 minutes à s’exécuter
- Cause 3 : la non exécution de la procédure de clean up toutes les 10 minutes.
- Cause 4 : une base qui existe depuis longtemps qui n’a jamais été cleanée

- Solution 1 :
Etape 1 : Aller sur le « report manager », allez dans « Site Settings », et cocher « Limit the copies of report history to : 10  » au lieu du paramètre par défaut.
Etape 2 :Ensuite faire du ménage sur votre plateforme de rapport s’il y en a besoin en supprimant des snapshots non utilisés.

- Solution 2 :
Revoir ces rapports qui prennent trop de temps. Aller sur la base « Reportservertempdb » et exécuter la requête suivante pour les identifier :
 »
select Name, exe.UserName, exe.TimeStart, exe.TimeEnd, DATEDIFF(second,exe.TimeStart, exe.TimeEnd) as DureeEnSeconde
from [ReportServer].[dbo].[ExecutionLogStorage] exe,
[ReportServer].[dbo].[Catalog] cat
where cat.ItemID = exe.ReportID
ORDER BY DATEDIFF(second,exe.TimeStart, exe.TimeEnd) desc »

- Solution 3 :
Aller dans le fichier de Log de votre instance SSRS et regarder s’il y a un message d’erreur concernant la tâche CleanBatch

- Solution 4 :
Possibilité 1 : Vous pouvez choisi cette première possibilité peu extrême et faire ces étapes :
Etape 1 : éteindre le service report serveur
Etape 2 : exécuter un TRUNCATE des tables
Etape 3 : faire un shrink des fichiers de base de données
Etape 4 : redémarrer le service report serveur

Possibilité 2 : ou exécuter ce script pour un nettoyage en douceur :
 »
begin transaction

declare @cleanedSnapshots table (SnapshotDataId uniqueidentifier) ;
declare @cleanedChunks table (ChunkId uniqueidentifier) ;
declare @cleanedSegments table (ChunkId uniqueidentifier, SegmentId uniqueidentifier) ;
declare @deleteCount int ;

insert into @cleanedSnapshots
select distinct SnapshotDataId
from SegmentedChunk
where SnapshotDataId not in (select SnapshotDataID from SnapshotData)

– clean up chunks
set @deleteCount = 1 ;
while (@deleteCount > 0)
begin
delete top(20) SC
output deleted.ChunkId into @cleanedChunks(ChunkId)
from SegmentedChunk SC with (readpast)
join @cleanedSnapshots cs on SC.SnapshotDataId = cs.SnapshotDataId ;
set @deleteCount = @@ROWCOUNT ;
end ;

– clean up unused mappings
set @deleteCount = 1 ;
while (@deleteCount > 0)
begin
delete top(20) CSM
output deleted.ChunkId, deleted.SegmentId into @cleanedSegments (ChunkId, SegmentId)
from ChunkSegmentMapping CSM with (readpast)
join @cleanedChunks cc ON CSM.ChunkId = cc.ChunkId
where not exists (
select 1 from SegmentedChunk SC
where SC.ChunkId = cc.ChunkId )
and not exists (
select 1 from [ReportServerTempDB].dbo.SegmentedChunk TSC
where TSC.ChunkId = cc.ChunkId ) ;
set @deleteCount = @@ROWCOUNT ;
end ;

– clean up segments
set @deleteCount = 1
while (@deleteCount > 0)
begin
delete top(20) S
from Segment S with (readpast)
join @cleanedSegments cs on S.SegmentId = cs.SegmentId
where not exists (
select 1 from ChunkSegmentMapping csm
where csm.SegmentId = cs.SegmentId ) ;
set @deleteCount = @@ROWCOUNT ;
end

commit
 »

Possibilité 3 :ou encore exécuter :
DBCC CLEANTABLE (ReportServerTempDB,’dbo.Segment’, 0)
WITH NO_INFOMSGS;

Et vous? Avez vous déjà rencontré ce problème?