Pas d'écriture sur la base !? et pourtant elle fonctionne !...
3 réponses
Jean-Yves FREMONT
J'ai un souci avec une base en production...
Côté utilisateurs, tout fonctionne bien : les temps de réponse sont
excellents.
Le problème n'est pas là, Dieu merci.
Par contre sur le serveur :
1. Les dates de modification des fichiers
C:\Program Files\Microsoft SQL Server\MSSQLSERVER\Data\maBase_Data.MDF
C:\Program Files\Microsoft SQL Server\MSSQLSERVER\Data\maBase_Log.LDF
restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous
rassure)
2. Dans un fichier de trace la dernière ligne indique "le fichier journal de
la base est plein..."
(et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ).
Pourtant le journal est en extension automatique et il y a de place sur le
disque...
3. la sauvegarde du journal qui était parfois problématique au niveau du
volume est, depuis, ridiculement petite...
BREF : tout cela se passe comme s'il n'y avait aucune activité sur la
base... et pourtant ça fonctionne bien !
Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai
restaurée sur mon PC de développement :
tous les (nouveaux) enregistrements y sont. Tant mieux...
Les pistes :
le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt des
services MSSQLSERVER)
j'ai effectué des sauvegardes (base puis journal)
et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE).
Peut-être était-ce trop petit en l'occurence... et le fichier, une fois
réduit, était-il plein ?
Cela aurait-il pu perturber l'extension automatique ?
En pareil cas il n'y aurait pas plantage de l'ensemble ?
Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ?
Peut-on simplement augmenter sans risque la taille allouée au journal dans
les propriétés dela base ?
Quelles précautions (outre les sauvegardes, bien sûr) prendre ?
Si les dates de modification affichées des fichiers MDF et LDF sont
fiables...
peut-on penser que toutes les modifications effectuées depuis le 10/09/2004
sont seulement en mémoire ?
où sont-elles ? quand va-t-il écrire les modifs ?!
Bref : quels remèdes (médecine douce, de préférence) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
oulala, j'ai franchement rigolé (pas méchament, bien au contraire) en lisant ton mail qui prouve à l'évidence que tu ignore tout d'un SGBDR de type C/S comme Oracle, SQL Server ou Sybase, IBM DB, etc...
Y'a du boulot !
Un bon cours sur le sujet ne te ferais pas de mal...
Parce que pour expliquer tout cela en quelques lignes dans un forum, c'est à peu près aussi simple que de demander pourquoi un avion vole alors qu'il est plus lourd que l'air...
Mais mon site peut déjà t'aider.
En gros un SGBDR ouvre les fichiers des bases et les utilisent en permanence comme s'il gérait lui même ses fichiers avec son propre système de fichier et donc son propre OS, tant est si bien que l'OS ne voit rien passer !
Et grâce a quels mécanismes ? Le journal et les transactions.
N'hésite pas à lire et poser des questions précises.
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Jean-Yves FREMONT a écrit:
J'ai un souci avec une base en production... Côté utilisateurs, tout fonctionne bien : les temps de réponse sont excellents. Le problème n'est pas là, Dieu merci.
Par contre sur le serveur : 1. Les dates de modification des fichiers C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous rassure)
2. Dans un fichier de trace la dernière ligne indique "le fichier journal de la base est plein..." (et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ). Pourtant le journal est en extension automatique et il y a de place sur le disque...
3. la sauvegarde du journal qui était parfois problématique au niveau du volume est, depuis, ridiculement petite...
BREF : tout cela se passe comme s'il n'y avait aucune activité sur la base... et pourtant ça fonctionne bien !
Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai restaurée sur mon PC de développement : tous les (nouveaux) enregistrements y sont. Tant mieux...
Les pistes : le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt des services MSSQLSERVER) j'ai effectué des sauvegardes (base puis journal) et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE). Peut-être était-ce trop petit en l'occurence... et le fichier, une fois réduit, était-il plein ? Cela aurait-il pu perturber l'extension automatique ? En pareil cas il n'y aurait pas plantage de l'ensemble ? Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ? Peut-on simplement augmenter sans risque la taille allouée au journal dans les propriétés dela base ? Quelles précautions (outre les sauvegardes, bien sûr) prendre ?
Si les dates de modification affichées des fichiers MDF et LDF sont fiables... peut-on penser que toutes les modifications effectuées depuis le 10/09/2004 sont seulement en mémoire ? où sont-elles ? quand va-t-il écrire les modifs ?!
Bref : quels remèdes (médecine douce, de préférence) ?
Si vous avez des lumières... Merci d'avance.
oulala, j'ai franchement rigolé (pas méchament, bien au contraire) en lisant ton
mail qui prouve à l'évidence que tu ignore tout d'un SGBDR de type C/S comme
Oracle, SQL Server ou Sybase, IBM DB, etc...
Y'a du boulot !
Un bon cours sur le sujet ne te ferais pas de mal...
Parce que pour expliquer tout cela en quelques lignes dans un forum, c'est à peu
près aussi simple que de demander pourquoi un avion vole alors qu'il est plus
lourd que l'air...
Mais mon site peut déjà t'aider.
En gros un SGBDR ouvre les fichiers des bases et les utilisent en permanence
comme s'il gérait lui même ses fichiers avec son propre système de fichier et
donc son propre OS, tant est si bien que l'OS ne voit rien passer !
Et grâce a quels mécanismes ? Le journal et les transactions.
N'hésite pas à lire et poser des questions précises.
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Jean-Yves FREMONT a écrit:
J'ai un souci avec une base en production...
Côté utilisateurs, tout fonctionne bien : les temps de réponse sont
excellents.
Le problème n'est pas là, Dieu merci.
Par contre sur le serveur :
1. Les dates de modification des fichiers
C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF
C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF
restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous
rassure)
2. Dans un fichier de trace la dernière ligne indique "le fichier journal de
la base est plein..."
(et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ).
Pourtant le journal est en extension automatique et il y a de place sur le
disque...
3. la sauvegarde du journal qui était parfois problématique au niveau du
volume est, depuis, ridiculement petite...
BREF : tout cela se passe comme s'il n'y avait aucune activité sur la
base... et pourtant ça fonctionne bien !
Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai
restaurée sur mon PC de développement :
tous les (nouveaux) enregistrements y sont. Tant mieux...
Les pistes :
le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt des
services MSSQLSERVER)
j'ai effectué des sauvegardes (base puis journal)
et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE).
Peut-être était-ce trop petit en l'occurence... et le fichier, une fois
réduit, était-il plein ?
Cela aurait-il pu perturber l'extension automatique ?
En pareil cas il n'y aurait pas plantage de l'ensemble ?
Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ?
Peut-on simplement augmenter sans risque la taille allouée au journal dans
les propriétés dela base ?
Quelles précautions (outre les sauvegardes, bien sûr) prendre ?
Si les dates de modification affichées des fichiers MDF et LDF sont
fiables...
peut-on penser que toutes les modifications effectuées depuis le 10/09/2004
sont seulement en mémoire ?
où sont-elles ? quand va-t-il écrire les modifs ?!
Bref : quels remèdes (médecine douce, de préférence) ?
oulala, j'ai franchement rigolé (pas méchament, bien au contraire) en lisant ton mail qui prouve à l'évidence que tu ignore tout d'un SGBDR de type C/S comme Oracle, SQL Server ou Sybase, IBM DB, etc...
Y'a du boulot !
Un bon cours sur le sujet ne te ferais pas de mal...
Parce que pour expliquer tout cela en quelques lignes dans un forum, c'est à peu près aussi simple que de demander pourquoi un avion vole alors qu'il est plus lourd que l'air...
Mais mon site peut déjà t'aider.
En gros un SGBDR ouvre les fichiers des bases et les utilisent en permanence comme s'il gérait lui même ses fichiers avec son propre système de fichier et donc son propre OS, tant est si bien que l'OS ne voit rien passer !
Et grâce a quels mécanismes ? Le journal et les transactions.
N'hésite pas à lire et poser des questions précises.
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Jean-Yves FREMONT a écrit:
J'ai un souci avec une base en production... Côté utilisateurs, tout fonctionne bien : les temps de réponse sont excellents. Le problème n'est pas là, Dieu merci.
Par contre sur le serveur : 1. Les dates de modification des fichiers C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous rassure)
2. Dans un fichier de trace la dernière ligne indique "le fichier journal de la base est plein..." (et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ). Pourtant le journal est en extension automatique et il y a de place sur le disque...
3. la sauvegarde du journal qui était parfois problématique au niveau du volume est, depuis, ridiculement petite...
BREF : tout cela se passe comme s'il n'y avait aucune activité sur la base... et pourtant ça fonctionne bien !
Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai restaurée sur mon PC de développement : tous les (nouveaux) enregistrements y sont. Tant mieux...
Les pistes : le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt des services MSSQLSERVER) j'ai effectué des sauvegardes (base puis journal) et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE). Peut-être était-ce trop petit en l'occurence... et le fichier, une fois réduit, était-il plein ? Cela aurait-il pu perturber l'extension automatique ? En pareil cas il n'y aurait pas plantage de l'ensemble ? Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ? Peut-on simplement augmenter sans risque la taille allouée au journal dans les propriétés dela base ? Quelles précautions (outre les sauvegardes, bien sûr) prendre ?
Si les dates de modification affichées des fichiers MDF et LDF sont fiables... peut-on penser que toutes les modifications effectuées depuis le 10/09/2004 sont seulement en mémoire ? où sont-elles ? quand va-t-il écrire les modifs ?!
Bref : quels remèdes (médecine douce, de préférence) ?
Si vous avez des lumières... Merci d'avance.
Sylvain Lafontaine
Une suggestion: si la sauvegarde du journal est ridiculement petite, c'est peut-être que le mode de recouvrement dans les options est passée maintenant en mode Simple (ou Bulk Logged?) au lieu de Full (je ne connais pas les traductions françaises).
Je n'en dis pas plus car je ne connais pas la version SQL-Serveur que vous utilisez et il y a eu des changements entre la version 7 et la 2000.
S. L.
"Jean-Yves FREMONT" wrote in message news:
J'ai un souci avec une base en production... Côté utilisateurs, tout fonctionne bien : les temps de réponse sont excellents. Le problème n'est pas là, Dieu merci.
Par contre sur le serveur : 1. Les dates de modification des fichiers C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous rassure)
2. Dans un fichier de trace la dernière ligne indique "le fichier journal de la base est plein..." (et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ). Pourtant le journal est en extension automatique et il y a de place sur le disque...
3. la sauvegarde du journal qui était parfois problématique au niveau du volume est, depuis, ridiculement petite...
BREF : tout cela se passe comme s'il n'y avait aucune activité sur la base... et pourtant ça fonctionne bien !
Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai restaurée sur mon PC de développement : tous les (nouveaux) enregistrements y sont. Tant mieux...
Les pistes : le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt des services MSSQLSERVER) j'ai effectué des sauvegardes (base puis journal) et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE). Peut-être était-ce trop petit en l'occurence... et le fichier, une fois réduit, était-il plein ? Cela aurait-il pu perturber l'extension automatique ? En pareil cas il n'y aurait pas plantage de l'ensemble ? Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ? Peut-on simplement augmenter sans risque la taille allouée au journal dans les propriétés dela base ? Quelles précautions (outre les sauvegardes, bien sûr) prendre ?
Si les dates de modification affichées des fichiers MDF et LDF sont fiables... peut-on penser que toutes les modifications effectuées depuis le 10/09/2004 sont seulement en mémoire ? où sont-elles ? quand va-t-il écrire les modifs ?!
Bref : quels remèdes (médecine douce, de préférence) ?
Si vous avez des lumières... Merci d'avance.
Une suggestion: si la sauvegarde du journal est ridiculement petite, c'est
peut-être que le mode de recouvrement dans les options est passée maintenant
en mode Simple (ou Bulk Logged?) au lieu de Full (je ne connais pas les
traductions françaises).
Je n'en dis pas plus car je ne connais pas la version SQL-Serveur que vous
utilisez et il y a eu des changements entre la version 7 et la 2000.
S. L.
"Jean-Yves FREMONT" <Jean-Yves.Fremont@crous-rouen.fr> wrote in message
news:uBP1v7ymEHA.2764@TK2MSFTNGP11.phx.gbl...
J'ai un souci avec une base en production...
Côté utilisateurs, tout fonctionne bien : les temps de réponse sont
excellents.
Le problème n'est pas là, Dieu merci.
Par contre sur le serveur :
1. Les dates de modification des fichiers
C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF
C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF
restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous
rassure)
2. Dans un fichier de trace la dernière ligne indique "le fichier journal
de
la base est plein..."
(et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ).
Pourtant le journal est en extension automatique et il y a de place sur le
disque...
3. la sauvegarde du journal qui était parfois problématique au niveau du
volume est, depuis, ridiculement petite...
BREF : tout cela se passe comme s'il n'y avait aucune activité sur la
base... et pourtant ça fonctionne bien !
Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai
restaurée sur mon PC de développement :
tous les (nouveaux) enregistrements y sont. Tant mieux...
Les pistes :
le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt
des
services MSSQLSERVER)
j'ai effectué des sauvegardes (base puis journal)
et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE).
Peut-être était-ce trop petit en l'occurence... et le fichier, une fois
réduit, était-il plein ?
Cela aurait-il pu perturber l'extension automatique ?
En pareil cas il n'y aurait pas plantage de l'ensemble ?
Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ?
Peut-on simplement augmenter sans risque la taille allouée au journal dans
les propriétés dela base ?
Quelles précautions (outre les sauvegardes, bien sûr) prendre ?
Si les dates de modification affichées des fichiers MDF et LDF sont
fiables...
peut-on penser que toutes les modifications effectuées depuis le
10/09/2004
sont seulement en mémoire ?
où sont-elles ? quand va-t-il écrire les modifs ?!
Bref : quels remèdes (médecine douce, de préférence) ?
Une suggestion: si la sauvegarde du journal est ridiculement petite, c'est peut-être que le mode de recouvrement dans les options est passée maintenant en mode Simple (ou Bulk Logged?) au lieu de Full (je ne connais pas les traductions françaises).
Je n'en dis pas plus car je ne connais pas la version SQL-Serveur que vous utilisez et il y a eu des changements entre la version 7 et la 2000.
S. L.
"Jean-Yves FREMONT" wrote in message news:
J'ai un souci avec une base en production... Côté utilisateurs, tout fonctionne bien : les temps de réponse sont excellents. Le problème n'est pas là, Dieu merci.
Par contre sur le serveur : 1. Les dates de modification des fichiers C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous rassure)
2. Dans un fichier de trace la dernière ligne indique "le fichier journal de la base est plein..." (et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ). Pourtant le journal est en extension automatique et il y a de place sur le disque...
3. la sauvegarde du journal qui était parfois problématique au niveau du volume est, depuis, ridiculement petite...
BREF : tout cela se passe comme s'il n'y avait aucune activité sur la base... et pourtant ça fonctionne bien !
Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai restaurée sur mon PC de développement : tous les (nouveaux) enregistrements y sont. Tant mieux...
Les pistes : le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt des services MSSQLSERVER) j'ai effectué des sauvegardes (base puis journal) et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE). Peut-être était-ce trop petit en l'occurence... et le fichier, une fois réduit, était-il plein ? Cela aurait-il pu perturber l'extension automatique ? En pareil cas il n'y aurait pas plantage de l'ensemble ? Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ? Peut-on simplement augmenter sans risque la taille allouée au journal dans les propriétés dela base ? Quelles précautions (outre les sauvegardes, bien sûr) prendre ?
Si les dates de modification affichées des fichiers MDF et LDF sont fiables... peut-on penser que toutes les modifications effectuées depuis le 10/09/2004 sont seulement en mémoire ? où sont-elles ? quand va-t-il écrire les modifs ?!
Bref : quels remèdes (médecine douce, de préférence) ?
Si vous avez des lumières... Merci d'avance.
Jean-Yves FREMONT
J'utilise Microsoft Server 2000 et la base est bien en mode "complet", par opposition à "journalisé en bloc" ou "simple", in french ;-) Merci de votre intérêt pour mon problème.
JYF
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Une suggestion: si la sauvegarde du journal est ridiculement petite, c'est peut-être que le mode de recouvrement dans les options est passée
maintenant
en mode Simple (ou Bulk Logged?) au lieu de Full (je ne connais pas les traductions françaises).
Je n'en dis pas plus car je ne connais pas la version SQL-Serveur que vous utilisez et il y a eu des changements entre la version 7 et la 2000.
S. L.
"Jean-Yves FREMONT" wrote in message news: > J'ai un souci avec une base en production... > Côté utilisateurs, tout fonctionne bien : les temps de réponse sont > excellents. > Le problème n'est pas là, Dieu merci. > > Par contre sur le serveur : > 1. Les dates de modification des fichiers > C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF > C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF > restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous > rassure) > > 2. Dans un fichier de trace la dernière ligne indique "le fichier
journal
> de > la base est plein..." > (et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ). > Pourtant le journal est en extension automatique et il y a de place sur
le
> disque... > > 3. la sauvegarde du journal qui était parfois problématique au niveau du > volume est, depuis, ridiculement petite... > > BREF : tout cela se passe comme s'il n'y avait aucune activité sur la > base... et pourtant ça fonctionne bien ! > > Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai > restaurée sur mon PC de développement : > tous les (nouveaux) enregistrements y sont. Tant mieux... > > Les pistes : > le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt > des > services MSSQLSERVER) > j'ai effectué des sauvegardes (base puis journal) > et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE). > Peut-être était-ce trop petit en l'occurence... et le fichier, une fois > réduit, était-il plein ? > Cela aurait-il pu perturber l'extension automatique ? > En pareil cas il n'y aurait pas plantage de l'ensemble ? > Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ? > Peut-on simplement augmenter sans risque la taille allouée au journal
dans
> les propriétés dela base ? > Quelles précautions (outre les sauvegardes, bien sûr) prendre ? > > Si les dates de modification affichées des fichiers MDF et LDF sont > fiables... > peut-on penser que toutes les modifications effectuées depuis le > 10/09/2004 > sont seulement en mémoire ? > où sont-elles ? quand va-t-il écrire les modifs ?! > > Bref : quels remèdes (médecine douce, de préférence) ? > > Si vous avez des lumières... Merci d'avance. > > >
J'utilise Microsoft Server 2000 et la base est bien en mode "complet", par
opposition à "journalisé en bloc" ou "simple", in french ;-)
Merci de votre intérêt pour mon problème.
JYF
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a
écrit dans le message de news:uFgvyD0mEHA.632@TK2MSFTNGP12.phx.gbl...
Une suggestion: si la sauvegarde du journal est ridiculement petite, c'est
peut-être que le mode de recouvrement dans les options est passée
maintenant
en mode Simple (ou Bulk Logged?) au lieu de Full (je ne connais pas les
traductions françaises).
Je n'en dis pas plus car je ne connais pas la version SQL-Serveur que vous
utilisez et il y a eu des changements entre la version 7 et la 2000.
S. L.
"Jean-Yves FREMONT" <Jean-Yves.Fremont@crous-rouen.fr> wrote in message
news:uBP1v7ymEHA.2764@TK2MSFTNGP11.phx.gbl...
> J'ai un souci avec une base en production...
> Côté utilisateurs, tout fonctionne bien : les temps de réponse sont
> excellents.
> Le problème n'est pas là, Dieu merci.
>
> Par contre sur le serveur :
> 1. Les dates de modification des fichiers
> C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF
> C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF
> restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous
> rassure)
>
> 2. Dans un fichier de trace la dernière ligne indique "le fichier
journal
> de
> la base est plein..."
> (et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ).
> Pourtant le journal est en extension automatique et il y a de place sur
le
> disque...
>
> 3. la sauvegarde du journal qui était parfois problématique au niveau du
> volume est, depuis, ridiculement petite...
>
> BREF : tout cela se passe comme s'il n'y avait aucune activité sur la
> base... et pourtant ça fonctionne bien !
>
> Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai
> restaurée sur mon PC de développement :
> tous les (nouveaux) enregistrements y sont. Tant mieux...
>
> Les pistes :
> le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt
> des
> services MSSQLSERVER)
> j'ai effectué des sauvegardes (base puis journal)
> et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE).
> Peut-être était-ce trop petit en l'occurence... et le fichier, une fois
> réduit, était-il plein ?
> Cela aurait-il pu perturber l'extension automatique ?
> En pareil cas il n'y aurait pas plantage de l'ensemble ?
> Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ?
> Peut-on simplement augmenter sans risque la taille allouée au journal
dans
> les propriétés dela base ?
> Quelles précautions (outre les sauvegardes, bien sûr) prendre ?
>
> Si les dates de modification affichées des fichiers MDF et LDF sont
> fiables...
> peut-on penser que toutes les modifications effectuées depuis le
> 10/09/2004
> sont seulement en mémoire ?
> où sont-elles ? quand va-t-il écrire les modifs ?!
>
> Bref : quels remèdes (médecine douce, de préférence) ?
>
> Si vous avez des lumières... Merci d'avance.
>
>
>
J'utilise Microsoft Server 2000 et la base est bien en mode "complet", par opposition à "journalisé en bloc" ou "simple", in french ;-) Merci de votre intérêt pour mon problème.
JYF
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> a écrit dans le message de news:
Une suggestion: si la sauvegarde du journal est ridiculement petite, c'est peut-être que le mode de recouvrement dans les options est passée
maintenant
en mode Simple (ou Bulk Logged?) au lieu de Full (je ne connais pas les traductions françaises).
Je n'en dis pas plus car je ne connais pas la version SQL-Serveur que vous utilisez et il y a eu des changements entre la version 7 et la 2000.
S. L.
"Jean-Yves FREMONT" wrote in message news: > J'ai un souci avec une base en production... > Côté utilisateurs, tout fonctionne bien : les temps de réponse sont > excellents. > Le problème n'est pas là, Dieu merci. > > Par contre sur le serveur : > 1. Les dates de modification des fichiers > C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Data.MDF > C:Program FilesMicrosoft SQL ServerMSSQLSERVERDatamaBase_Log.LDF > restent bloquées au 10/09/2004... (et il n'y en a pas d'autre, je vous > rassure) > > 2. Dans un fichier de trace la dernière ligne indique "le fichier
journal
> de > la base est plein..." > (et cette ligne est toujours la dernière depuis le... 10/09/2004 ! ). > Pourtant le journal est en extension automatique et il y a de place sur
le
> disque... > > 3. la sauvegarde du journal qui était parfois problématique au niveau du > volume est, depuis, ridiculement petite... > > BREF : tout cela se passe comme s'il n'y avait aucune activité sur la > base... et pourtant ça fonctionne bien ! > > Coté bonne nouvelle : j'ai sauvegardé la base de production et je l'ai > restaurée sur mon PC de développement : > tous les (nouveaux) enregistrements y sont. Tant mieux... > > Les pistes : > le 10/09/2004, à l'occasion d'une mise à jour de l'appli (et de l'arrêt > des > services MSSQLSERVER) > j'ai effectué des sauvegardes (base puis journal) > et j'ai ramené la taille du journal à 1Mo (DBCC SHRINKFILE). > Peut-être était-ce trop petit en l'occurence... et le fichier, une fois > réduit, était-il plein ? > Cela aurait-il pu perturber l'extension automatique ? > En pareil cas il n'y aurait pas plantage de l'ensemble ? > Comment augmenter la taille (opération inverse de DBCC SHRINKFILE) ? > Peut-on simplement augmenter sans risque la taille allouée au journal
dans
> les propriétés dela base ? > Quelles précautions (outre les sauvegardes, bien sûr) prendre ? > > Si les dates de modification affichées des fichiers MDF et LDF sont > fiables... > peut-on penser que toutes les modifications effectuées depuis le > 10/09/2004 > sont seulement en mémoire ? > où sont-elles ? quand va-t-il écrire les modifs ?! > > Bref : quels remèdes (médecine douce, de préférence) ? > > Si vous avez des lumières... Merci d'avance. > > >
