Discussion :

[Bronks]

malgre une sauvegarde de mon fichier log je n'arrive pas a reduire mon fichier log qui fait maintenant 427 Mo (il se reduire apres sauvegarde mais ne se reduit jamais en dessous de 400)

j'ai fait pour tant un
DBCC SHRINKFILE(mabase_log, 10)

mais

DBCC SQLPERF(LOGSPACE)
>Mabase 427M 17% used




une idée ?

[Coin]

salut,

je crois qu'il faut utiliser un

Code :

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

with truncate only

je crois qu'il faut regarder dans l'aide.

Si je m'en souvient je te tiens au courant.

Coin

[Bronks]

salut,

je crois qu'il faut utiliser un

Code :

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

with truncate only

je crois qu'il faut regarder dans l'aide.

Si je m'en souvient je te tiens au courant.

Coin

merci
j'ai deja essaye ca ...
et voila le retour
dbld Fileid CurrenSize mimSize UsedPages EstimatedPages
21 2 54760 128 54760 128

et mon fichier ne bouge pas en taille

[SQLpro]

Lisez l'article aue j'ai ecrit a ce sujet :http://sqlpro.developpez.com/cours/sqlserver/log/

De plus si votre fichier a ete cree avec une taille fixe de depart, il ne pourra jamais descendre en dessous de cette taille.

A +

[Bronks]

Lisez l'article aue j'ai ecrit a ce sujet :http://sqlpro.developpez.com/cours/sqlserver/log/

De plus si votre fichier a ete cree avec une taille fixe de depart, il ne pourra jamais descendre en dessous de cette taille.

A +

j'avais deja lu ton article merci

je pense plutot que c'est du a la taille initiale.

pour changer cette est ce que je peux sauvegarder la base puis le reprendre avec un plus petite journal d'evenement ? ou passer en mode recuperation simple temporairement ?

[usf70]

Tu pourrais faire la chose suivante:

1) détacher ta base de données (ex : EXEC sp_detach_db @dbname = 'pubs')
2) renommer ton fichier log en .old par exemple
3) rattacher ta base avec l'instruction sp_attach_single_file_db (ex: EXEC sp_attach_single_file_db @dbname = 'pubs',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf')

Tu ne lui donnes que le nom du fichier data. Il re-créera le fichier de log, avec une taille initiale par défaut.

PS : fais une sauvegarde de ta base avant. Et surtout ne supprimes pas l'ancien fichier de logs avant que l'opération soit OK.

[Crotte]

J'utilise cette procédure stockée (fichier joint) depuis un certain temps et je dois reconnaitre que j'en suis assez satisfait...

Elle traite l'ensemble des BDD du serveur et peut être lancée depuis n'importe quelle BDD.

Elle réduit la taile des fichiers MDF et LDF...

En revanche je ne sais pas ce que cela donne avec un fichier avec une taille de départ... jamais testé !

A toi de me le dire...

Tiens le code en visu quand même...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
 
create  procedure _xReducTailleBDD
/**********************************************************************
Type d'objet : Procédure stockée
Domaine : Administration/Tunning SQL Serveur
Objectif : Réduit la taille des journaux et base de données de toutes les bdd du serveur
Date : 20/06/2006
Auteur : Raoul CHRISMANN
**********************************************************************/
as
begin
 
declare
@dbName     varchar(254),
@cmd00      varchar(100),
@cmd01      varchar(50),
@cmd02      varchar(50),
@cmd20      varchar(100),
@cmd21      varchar(50),
@cmd22      varchar(50)
 
select @cmd01 = 'dump tran '
select @cmd02 = ' with no_log'
select @cmd21 = 'DBCC SHRINKDATABASE ('
select @cmd22 = ',10)'
 
declare curMaint cursor local forward_only for 
select name 
from master.dbo.sysdatabases 
-- bdd à exclure du traitement
where name not in ('master','tempdb','model','msdb','pubs','Northwind')
 
-- Affichage des informations avant traitement 
DBCC SQLPERF(LOGSPACE)
 
open curMaint
fetch next from curMaint into @dbName
  while @@FETCH_STATUS = 0
  begin
    --select  @dbName
    /* dump tran @dbName with no_log */
    select @cmd00 = @cmd01 + @dbName + @cmd02
    --select @cmd00
    exec (@cmd00)
 
    /* log file compression = DBCC SHRINKDATABASE (@dbName,10) */
    select @cmd20 = @cmd21 + rtrim(@dbName) + @cmd22
    --select @cmd20
    exec(@cmd20)
    fetch next from curMaint into @dbName
  end
 
close curMaint
deallocate curMaint
 
-- Affichage des informations après traitement 
DBCC SQLPERF(LOGSPACE)
 
end

[SQLpro]

Cette procédure est une hérésie... Passe encore de réduire inutilement le fichier du journal des transactions, mais celui de la base, c'est stupide et nuit gravement aux performances et conduit à des deadlocks sur un serveur chargé !

A +

[Bronks]

wouaaaa du calme

je veux juste avoir une solution , ne vous battez pas

en fait je pense que je vais suivre la procedure de detachement etc...

en faite cette taille initiale est due a une migration de la base de 2000 à 2005 ou mon fichier log faisait 400 Mo.

[Crotte]

Tu m'en veux ou quoi ?

Bon alors pour l'hérésie...

Il faut que tu saches quand même que le SQL pour du SQL c'est bien mais il ne faut pas perdre de vue qu'il y a souvent un logiciel qui insère, modifie et supprime des enregistrements.

Quand tu as la maitrise des sources de ces logiciels, tu peux traiter la BDD comme tu l'entends....

Mais malheureusement pour moi je travaille avec des BDD qui sont créées et structurées par un éditeur, qui lui doit faire tourner le même logiciel sur différentes BDD (Oracle, SQL Serveur, db2....). Et donc il est fréquent qu'elles ne respectent pas les règles de SQL Serveur... qui, je suis désolé de te le rappeler, n'est pas le seul SGBD sur terre...

Par ailleurs cette hérésie est en place chez tous mes clients et je n'ai JAMAIS rencontré de deadlock...

En revanche sans l'utiliser j'avais des fichiers LDF qui pouvaient faire le triple du fichier MDF... sur une BDD de 4 Go... un fichier log de 12... c'est vrai que de le réduire est inutile... nickel ne change rien !

[SQLpro]

Donc sp_detach_db et sp_attach_single_file_db.

A +