Discussion :

[stdebordeau]

Bonjour,
j'ai un entrepôt de données de 35GO (Base sql server 2012) qui se chargeait normalement en au plus 8h de temps avec des processus SSIS. Depuis un certain temps, le chargement met 15h et plus, sans que le volume de données ai significativement augmenté. ce qui est plus bizarre, c'est que quand je redémarre mon serveur, le premier chargement de l'entrepôt est normal (moins de 8h), puis à chaque chargement les jours suivants, la durée ne fait qu'augmenter. Ce devrait être le contraire puisque Sql server ne fais plus de plan de requête les fois suivantes. Merci d'avance pour votre aide.

Sql server 2012; Le serveur à 30Go de RAM dont 12Go dédié à Sql server; 14 processeurs virtuelles Bref du lourd quand même!

Ps: J'ai aussi posté ce message dans le forum dédié à SSIS

[darkelend]

Il peut y avoir énormément de facteurs qui pourraient expliquer cette dégradation de performance.
Regarde dans les Logs SSIS pour déterminer quelle étape prend plus de temps qu'avant.

Tu ne dédies que 12Go à SQL Server pour quelle raison ? Il y a d'autres applications sur le serveur ? 12Go pour un DWH de prod, ca peut faire léger en fonction de sa taille

[stdebordeau]

Dans les logs SSIS, je constate que toutes les étapes prennent plus de temps.
Oui, il y'a d'autres applications sur le serveur. En fait j'ai une trentaine de travaux programmés (Agent Sql Server) et qui s'exécutent en continu, mais qui s'arrêtent la nuit pour laisser place au chargement de l'entrepôt.

[SQLpro]

Est-ce que par hasard vous ne feriez pas un SHRINK en début de processus ????

A +

[stdebordeau]

à la fin du chargement de l'entrepôt, j'ai un package SSIS qui réalise les taches suivantes :

Réduire la base de données (Cette tache SSIS effectue peut être un SHRINK ?)
Reconstruire les index
Mettre à jour les statistiques
Sauvegarder la base de donnée.

Je crois savoir qu'il s'agit de bonnes pratiques pour augmenter la performance.

Je précise par ailleurs que la base est en mode de récupération simple, mon fichier de log prenait trop de volume.

[SQLpro]

à la fin du chargement de l'entrepôt, j'ai un package SSIS qui réalise les taches suivantes :

Réduire la base de données (Cette tache SSIS effectue peut être un SHRINK ?)

C'est là qu'est l'imbécilité !

...

Je précise par ailleurs que la base est en mode de récupération simple, mon fichier de log prenait trop de volume.

pas de soucis.

Pour savoir pourquoi c'est une imbécilité lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p5..._fichiers_et_t

Pour y remédier : taille vos fichiers de données ET VOTRE JOURNAL DE TRANSACTION, à un peu plus que le maximum atteint précédemment !

Et si vous avez pas assez de place... achetez-en ou subissez bêtement !
En informatique, comme dans bien des domaines... Il n'y a pas de miracles...

A +

[stdebordeau]

Des méconnaissances en matière d'administration de base de données ? certainement (personne n'est parfait), mais pas de l'imbécillité. Par ailleurs, je ne subirai pas bêtement, heureusement que j'ai de l'espace. Je vais augmenter la taille de mes fichiers, et désactiver la tache de réduction.

Je vous remercie pour votre aide, mais je trouve que vous y allez un peu fort

[SQLpro]

Je vous remercie pour votre aide, mais je trouve que vous y allez un peu fort

C'est pas à 54 ans que je vais me refaire, d'autant plus que j'ai décidé d'être le "terminator" du SQL. En effet, j'ai tâté la période "sissi" et visiblement les internautes se foutait totalement de ce que je disais ! À partir du moment ou j'ai changé d'angle en devenant "terminator", les gens ont violemment réagis, et c'est bien ce que j'espérais... Des réactions !
Même vous êtes tombé dans le panneau...
Or on apprend mieux de ses échecs que de ses réussites. Et c'est en mordant la poussière que l'on se souvient de ce qu'il ne faut pas faire.
D'ailleurs cela m'amuse toujours que les gens réagissent !

A +

[stdebordeau]

Bon! d'accord professeur, je digère!

Hier j'ai donc désactivé la réduction automatique , et j'ai fixé la taille de ma base à 100Go (elle faisait 35Go).
Ce matin, je constate que la chargement à duré 9h contre 8h habituellement après redémarrage.
Je constate aussi que la taille de la base est redescendu toute seule à 39Go (Au lieu des 100Go fixé), est ce normal ?

Je vais procéder à la mise à jour du Sp2 pour voir si ça s'améliore demain

Ps: Je n'arrive pas à accéder au dossier catalogue SSIS dans Sql management studio, il me renvoie l'erreur 1222. Peut être y'a t'il trop de travaux qui tournent en même temps ?

Merci

[Invité]

Je constate aussi que la taille de la base est redescendu toute seule à 39Go (Au lieu des 100Go fixé), est ce normal ?

Non ce n'est pas normal.
Est-ce que l'option Auto-Shrink est activé sur la bd ?
Sinon, il y a une tâche de shrink automatique qui fait partie de tes jobs.

[stdebordeau]

Non, cette option n'est pas activé.

[Invité]

Non, cette option n'est pas activé.

Alors tu as une tâche qui fait ça.
As-toi de la retrouvé !
J'ai remarqué que cette tâche de shrink fait parfois parti de la sauvegarde Full quotidienne mais bon, tu n'as pas le choix que d'aller vérifier...

[stdebordeau]

Mise à jour du sp2, arrêt de la tache de sauvegarde SSIS, j'avais aussi une tache de réduction de la base de données lors du déchargement initial de l'entrepôt, désactivé elle aussi.
ça fait 3 jours maintenant que tout semble revenir à la normal. Merci pour votre aide

[SQLpro]

CQFD !

A +