Discussion :

[Actarus69]

bonjour,
tout est dans le titre.
En MSSQL 2000 , quelle est l'option ou la commande qui me premet d'éxécuter une requête sans que le serveur ne stock ce qu'il fait dans le journal des trasactions ?

Merci

[SQLpro]

Il faut utiliser le niveau d'isolation le plus bas, soit par la commande SET ISOLATION LEVEL READ UNCOMMITTED, soit placer des tag NOLOCK dans les requêtes.

Mais attention aux risques extrêmes de désintégration des données, notamment dans les mises à jour...

A +

[Actarus69]

Merci j'éssaye tout ça.

[Actarus69]

En faite je m'apperçois que je n'ai peut pas été très clair...
Je veux faire de l'insert en base sans que la transcation soit stockée dans le journal des transcations pourquoi me direz vous.
Car je manipule des bases assez conséquentes (48 Go avec 90 millions d'enreg et tous dans la même table , je sais c'est pourri , mais je ne sui pas à l'origine de cette belle m.....), et je suis en train de les découper par ans en faisant des éxports (une année = +/- 15 millions d'enreg).
Pour des questions de rapidité d'éxécution , j'aimerais que l'insert se fasse sans sauvegarde de la transaction...car quand je vois la taille du, journal des transactions à la fin (20 Go pour l'insert de 6 mois) , je pense qu'une bonne partie de la transactions est utilisée par le remplissage du journal...
Ensuite je le vide avec les commandes qui vont bien en moins de 2 secondes , donc si je pouvais éviter de le remplir...

si quelqu'un a la solution ?

[SQLpro]

Il est strictement impossible de se passer du JT pour la mise à jour des données (INSERT, UPDATE, DELETE... ALTER...).
Et cela d'ailleurs quelque soit le SGBDR. Sinon, passez par des fichiers COBOL. C'est ce qu'il y a de plus rapide !

Mais en revanche vous devez faire le menage régulièrement du JT.
Pour cela, si vous trouvez qu'il grossit trop, il faut le "SHRINKER". Pour le shrinker, il faut préalablement le sauvegarder...

Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/log/

Mais compte tenu du volume de vos bases, je vous invite à suivre d'urgence un cours d'administration de MS SQL Server. Car avec un tel volume de données, si vous perdez la base, ce qui est facile à faire quand on ne maitrise pas la chose, je ne vous promet plus aucun avenir dans le monde informatique. Pensez que les données, c'est un capital très important pour l'entreprise !
Certaines entreprises sont mortes à la suite de la perte de leurs données informatiques. Voir l'étude consacré à ce sujet après les attaques terroristes du 11 septembre dans SQL mag.

A +

[Actarus69]

merci pour vos conseils , enfaite je manipule ce genre de bases depuis assez longtemps déjà, je maitrise plus ou moins correctement toutes les procédures de sauvegardes d'optimasations et autres.
j'ai plus qu'à mon habitude été confronté à des bases supsectes...et j'ai appris à parer ce genre d'éventualité..

toutes mes bases , sont des bases "de productions" donc les fichiers sont figés et sauvegardés sur des suports différents et au moins en trois éxemplaires...car avec le temps je me suis apperçus que le plus éfficace était encore de sauvegardes les fichiers en eux même plutôt que de se fier au fichier de backup de MSSQL (encore que de gros progrés est été réalisés depusi la version 7)...
Et puis j'ai des serveurs de backup qui se répliquent journalièrement via des applicatif éxternes developpés pour....bref je ne suis pas novice , mis je n'ai jamais su si oui ou non on pouvait se passer du journal des transaction , je croyais avoir lu que si....
sinon pour vide le journal rapidement et éfficacement (sans le sauvegarder car je n'ai pas besoin de revenir en arrière ), je procède comme suit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
BACKUP LOG Nomdelabase WITH TRUNCATE_ONLY;
DBCC SHRINKFILE('nomdufichierlogdelabase');

[SQLpro]

Je fait du conseil et de l'audit sur MS SQL Server depuis maintenant plus de 10 ans et je travaille sur des volume conséquent (plus de 1 To). A partir de la V 2000, je n'ai jamais eu un cas de corruption de données qui ne soit pas soit un cas de fausse manip, soit une perte de disque.

Encore faut-il mettre en place les bonnes méthodes.

A +