SQL-Server2000 et accroissement TEMPDB

Version imprimable

03/09/2007, 15h13
DOMINO53

SQL-Server2000 et accroissement TEMPDB

Bonjour à tous,

J'ai une interrogation quant à la démarche pour solutionner un pb récurrent à savoir :
DESCRIPTION : Erreur : 9002, Gravité : 17, État : 6
Le fichier journal de la base de données ‘tempdb’ est plein. Pour libérer de la place, sauvegardez le journal des transactions.

Quant nous interrogeons la base TEMPDB, nous n'avons aucun souci,Hormi le fait que,par les requetes BO, la base est passé de 4 gigas à 31 gigas. Elle se réinitialise à 4 gigas lors de notre reboot hebdo.

Nous avons des interrogations sur l'impact de cette accroissement sur les performances jusqu'au prochain reboot. Que pourrions nous envisager : Réorg, compactage au autre , modid d'une propriété ...?

Merci à tous
03/09/2007, 16h00
serge0934

il te faut créer une tache de sauvegarde (job) du journal de transaction
tu le programmes pour une execution journalière
03/09/2007, 17h50
SQLpro

assurez vous que la base tempdb est en mode de recouvrement simple, cela minimisera le jt et récuperera automatiquement les parties obsolète sans faire usage d'aucune tâche quotidienne ou autre.

Evitez de stopper un serveur SQL. Ceci est un non sens absolu. Vous perdez toute la mise en cache et donc les performances redeviennent mauvais au démarrage. Les SGBDR comme SQL Server sont fait pour tourner 99,999 % du temps soit 5 minutes d'interruption par ans (juste de quoi passer un patch !).

A +
04/09/2007, 10h29
Ptit_Dje

Citation:

Envoyé par SQLpro

Les SGBDR comme SQL Server sont fait pour tourner 99,999 % du temps soit 5 minutes d'interruption par ans (juste de quoi passer un patch !).

Si ca pouvait etre vrai un taux de disponibilité pareil ... !!!
04/09/2007, 11h00
SQLpro

non seulement c'est vrai, mais c'est même l'exigence de certains clients.
Sachez que HP propose ce genre de services pour SQL Server depuis plusieurs années.

http://www.sql-server-performance.co...bility_p1.aspx

A +
04/09/2007, 11h16
Ptit_Dje

Je ne comprend juste pas ou vous trouvez le temps pour appliquer tous les patches d'une année dans une fourchette de 5 minutes ! Soit vous ne patchez pas régulièrement, soit vous avez des serveurs qui redémarrent au quart de seconde.

Si vous avez une autre technique, je vous serais très reconnaissant de me (nous) la faire partager.
04/09/2007, 13h44
SQLpro

Il ne sert pas à grand chose de passer tous les patch un par un, sauf si vous êtes confrontés au problème exposé dans le patch.
En l'occurrence je parle donc des pacth cumulatifs qui sont en fait de l'ordre de 1 par an. (Exemple sql server 2000 : 5 patch cumulatif dit "Service Pack")

De plus effectivement il faut dimensionner son serveur (machine physique) à la mesure du service attendu. Cela veut dire que si vous achetez vos serveurs rue mongallet, ne vous attendez pas effectivement qu'ils redémarre très vite. Les deux serveurs de test que j'utilise redémarrent en moins de 25secondes.
Pour un SGBDR les ressources de RAM, processeurs et disques sont très importantes.

A +
04/09/2007, 14h49
Ptit_Dje

Microsoft sortant plus d'un patch de securité par an, je pense qu'il est nécessaire de tous les appliquer dès qu'ils sont disponibles et ce pour prévenir toute intrusion. N'appliquer que le service pack une fois par an peut être une solution pour maintenir ses serveurs online mais qu'en est il du reste de la sécurité et de tous les risques liés à celle-ci ?

Pour ce qui est de la configuration des serveurs sur lesquels je travaille, ils n'ont certainement pas été acheté rue Mongallet, bien que je ne sais pas vraiment ce qui s'y vend.
04/09/2007, 15h28
SQLpro

la plupart des patch intermédiaires sont des patchs correctifs fonctionnels, pas des patch de sécurité !

A +
04/09/2007, 19h00
Ptit_Dje

Je reste tout de même septique.
Je ne parle pas uniquement des patches sécurité liés à SQL Server en particulier mais bien de ceux de Windows aussi qui sortent presque mensuellement.
Pour moi 99.999% ca reste beau en théorie.
Bonne soirée.
17/09/2007, 15h13
DOMINO53

En attendant tous ces discours ne m'ont pas donné la réponse à ma question :
Ou trouve t-on la taille initiale de TEMPDB qui va être utilisé au prochain reboot du serveur (Table System, Procédures stockés, commandes DBCC ou autre = ?
Merci à tous

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
select * 
from master.dbo.sysaltfiles
WHERE status & 0x40 = 0x40
 
SELECT *
FROM sys.sysfiles
WHERE status & 0x40 = 0x40
 
select * 
from sys.database_files
WHERE type = 1

A +