Bonjour,
est il possible d'annuler l'écriture dans le journal de transaction? si oui comment le faire?
Merci d'avance pour vos aides.
:mrgreen:
Version imprimable
Bonjour,
est il possible d'annuler l'écriture dans le journal de transaction? si oui comment le faire?
Merci d'avance pour vos aides.
:mrgreen:
La réponse est NON. SQL server comme tous les SGBD a besoin d'1 journal de transaction pour écrire toutes les transactions effectuées sur les bases. Quand on démarre SQL server, le moteur lit d'abord ce journal "intime" pour identifier ce qu'il doit commencer par faire, concernant l'état des objets... Sans ce journal, pas de base...Citation:
Envoyé par AJemni
A+
Etienne ZINZINDOHOUE
Bonsoir,
Quelle drôle d'idée vous avez !!Citation:
Est il possible d'annuler l'écriture dans le journal de transaction? si oui comment le faire?
Quelle idée avez vous derrière cette question ? Que voulez vous faire exactement ?
++
Si vous préférez vous passer d'un journal de transactions, alors utilisez des fichiers COBOL !
A +
Bonjour,
mon besoin est le suivant :
j'ai un très grand fichiers texte de l'ordre de 1.5 Go de taille, mon application C# utilise un objet SqlBulkCopy du frameWork 2.0, cet objet se base essentiellement sur Bulk Insert (c'est exactement comme bcp)
le problème c'est que lors de l'exécution du prg les ressources occupées par Sql Server augmente constamment et il atteint 1.5Go de ram et puis le prg se crache en me signalant un dépassement de délais d'attente.
alors j'ai eu l'idée de s'en passer de l'écriture dans le fichiers journal car jamais je ferais une restauration et si une erreur apparait dans l'insertion je refais tous.
Si quelqu'un a une idée qui me permet d'insérer tous mes données dans la base sans que le serveur bouffe tous les ressources je serai ravis de la connaitre.
Merci d'avance
:mrgreen:
Bonjour,
Le fait que SQL Server consomme toute la mémoire disponible est tout à fait normal.
En effet, il travaille exclusivement en RAM pour diminuer les temps de traitement.
Pensez à ce que cela donnerait si tous les accès aux données se faisaient depuis ou vers le disque : une lenteur exceptionnelle ;)
En revanche pour éviter de faire gonfler le fichier du journal de transactions pour vos opérations d'import en masse, vous pouvez utiliser le mode de récupération BULK_LOGGED :
@++ ;)Code:ALTER DATABASE maBD SET RECOVERY BULK_LOGGED
Il faudra en plus de BULK_LOGGED vérifier s'il n'y a pas de contrainte, de trigger sur la table et idéalement pas d'index, de clé primaire avant de charger, etc... BULK INSERT a une propriété TABLOCK pour verrouiller toute la table avant d'importer, il doit y avoir un équivalent dans SqlBulkCopy.
* http://msdn.microsoft.com/en-us/library/ms190421.aspx
Votre application C# est-elle hébergée sur la même machine que le serveur SQL ?Citation:
Envoyé par AJemni
Si oui, alors il faut envisager avoir un serveur SQL dédié, c'est à dire séparé ton appli de l'SGBD,
pour enfin allouer suffisamment de mémoire à SQL (commutateur /3GB ou AWE selon la config du serveur),....
A +
Etienne ZINZINDOHOUE
Tout à fait, par défaut sqlBulkCopy n'utilise pas l'option TABLOCK. (à OFF)Citation:
il doit y avoir un équivalent dans SqlBulkCopy
L'option est la suivante :
... cependant attention aux locks qui pourront être éventuellement générés pendant la phase d'import ... A prendre en compteCode:... SqlBulkCopyOptions.TableLock
Bonjour,
Merci à vous tous, le problème est résolut (ou presque :?)
en faite, j'ai, en quelque sorte, tout combiné :
- En modifiant le Modèle de journalisation en "Journalisé en Bloc" (elsuket)- En supprimant ensuite l'index sur la table (clé primaire) avant l'insertion en bloc mais sans ajouté l'option TableLock(dbaffaleuf)- En plus, en modifiant l'espace alloué a chaque fichier .ldf et .mdf car la base "model" qui est le modèle de chaque nouvelle base créer contient comme config : 1Mo d'espace alloué pour chaque fichier et la croissance des fichier est définit à 10%, et mon nouveau config défini est : 2000Mo pour le fichier mdf, 1000Mo pour ldf et 1000Mo comme croissance des fichiers.- Coté C# j'ai modifié un peut le code : mon prg exécute la SqlBulkCopy.WriteToServer pour une DataTable qui contient 5000 lignes (a chaque 5000 ligne je lance la BulkInsert car si je rempli la DataTable par le fichier en entier qui est de taille 1.5Go le programme se crache dés le début avec une execption OutOfMemoryException ;)), c'est à dire que l'appel à BulkCopy est repétitif. Certe, le constructeur de SqlBulkCopy a 4 surcharges parmi eux 2 qui acceptent un seul paramètre : le premier string (une chaine de connexion) et le second SqlConnection, au début j'ai travaillé avec le premier (type de paramètre string) mais il parait que bulkcopy ouvre à chaque appel une connexion au serveur (appel en boucle de SqlBulkCopy) ce qui consomme un petit peux en plus les ressources, alors j'ai travaillé avec le deuxième constructeur avec une connexion ouverte au début de traitement.
et après toutes ces modifications l'insertion se fait en 20min et l'ajout de l'index (primary key) coule 9min :yaisse:
mais il reste un souci : au cours du traitement la mémoire occupé par sql Server ne cesse d'augmenter et se stabilise à 1.4Go et quand tout le traitement s'achève la mémoire occupé par le serveur SQL reste toujours 1.4Go ce qui m'oblige à redémarrer le serveur 8O, un vrai problème : j'ai pas le droit de redémarrer le serveur sql !!!
Comment faire pour actualiser le serveur?
Une fois que SQL Server a reservé sa mémoire pour son utilisation il ne la libérera pas à moins d'y être contraint par une demande du système d'exploitation.
En fonction de la quantité de mémoire de votre serveur vous pouvez limiter la mémoire maximum que pourra prendre SQL Server.
++Code:EXEC sp_configure 'max server memory (MB)'', <valeur>
Merci mikedavem,
je vais essayer de limiter la mémoire max de SQL Server et je verrai l'impact sur l'exécution du prg.
:mrgreen:
Salut,
J'ai modifié la taille mémoire de mon serveur local à 1000 MB (ancienne valeur 2048 MB) et le traitement d'insertion en bloc est achevé mais avec un temps plus grand (~60min) et l'espace mémoire occupé par le serveur SQL reste stable à 820MB. la modification est sur ma machine local car je ne peux rien modifier dans le serveur puisque je ne suis pas un admin sur le serveur et que plusieurs autres base sont attachées.
Merci à vous et maintenant je sais que mon fichier contenait 9.487.191 lignes
:mrgreen: