Bonjour la communauté,
Bon, je suis un peu novice sur SQL et je vous expose donc mon interrogation.
J'ai une base qui est utilisé par une plate forme de scan de facture.
Des factures sont numérisés par un scanner, puis vérifié par un module et
enfin, traitées par les utilisatrices.
Toutes ces opérations alimentent une base que je nommerais "ehs".
Le problème est le suivant :
La taille de la base augmente de 1 voire 2 Go par jour.
Elle fait actuellement 8 Go ( Données 4Go / Journaux 4 Go )
Espace disponible 0 Mo.
Je suis toujours en train de faire une sauvegarde des journaux pour
récupérer de temps en temps qq Mo.
Je voulais savoir quel conseil me donneriez vous pour gérer une telle base
si sollicitée.
Les plans de maintenances dans l'interface Enteprise Manager sont ils
efficaces ?
Enfin voilà,
J'ai souvent des blocages au niveau utilisateurs car l'inscription des
journaux est saturé.
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
Philippe T [MS]
Bonjour,
Oui il faut mettre en place des plans de maintenance. Faire un "shrink" des logs de la base lors de chaque backup full des informations (permet de réduire la taille du log). Il ne faut pas liasser SQL agrandir lui même les fichiers mais faire plutôt un peu de Capacity Planning et prévoyant une taille pour les données suffisante pour par exemple une semaine et agrandire par une procédure d'exploitation la taille des fichiers pendant des périodes "calmes".
Phil. ________________________________________________________ Philippe TROTIN Microsoft Services France http://www.microsoft.com/france "Emji" wrote in message news:
Bonjour la communauté, Bon, je suis un peu novice sur SQL et je vous expose donc mon interrogation.
J'ai une base qui est utilisé par une plate forme de scan de facture. Des factures sont numérisés par un scanner, puis vérifié par un module et enfin, traitées par les utilisatrices.
Toutes ces opérations alimentent une base que je nommerais "ehs". Le problème est le suivant :
La taille de la base augmente de 1 voire 2 Go par jour. Elle fait actuellement 8 Go ( Données 4Go / Journaux 4 Go ) Espace disponible 0 Mo.
Je suis toujours en train de faire une sauvegarde des journaux pour récupérer de temps en temps qq Mo.
Je voulais savoir quel conseil me donneriez vous pour gérer une telle base si sollicitée. Les plans de maintenances dans l'interface Enteprise Manager sont ils efficaces ? Enfin voilà, J'ai souvent des blocages au niveau utilisateurs car l'inscription des journaux est saturé.
Merci pour votre aide.
Bonjour,
Oui il faut mettre en place des plans de maintenance. Faire un "shrink" des
logs de la base lors de chaque backup full des informations (permet de
réduire la taille du log). Il ne faut pas liasser SQL agrandir lui même les
fichiers mais faire plutôt un peu de Capacity Planning et prévoyant une
taille pour les données suffisante pour par exemple une semaine et agrandire
par une procédure d'exploitation la taille des fichiers pendant des périodes
"calmes".
Phil.
________________________________________________________
Philippe TROTIN
Microsoft Services France http://www.microsoft.com/france
"Emji" <Emji@discussions.microsoft.com> wrote in message
news:2336F917-4ED6-45A9-8913-7E99D6FFEE9C@microsoft.com...
Bonjour la communauté,
Bon, je suis un peu novice sur SQL et je vous expose donc mon
interrogation.
J'ai une base qui est utilisé par une plate forme de scan de facture.
Des factures sont numérisés par un scanner, puis vérifié par un module et
enfin, traitées par les utilisatrices.
Toutes ces opérations alimentent une base que je nommerais "ehs".
Le problème est le suivant :
La taille de la base augmente de 1 voire 2 Go par jour.
Elle fait actuellement 8 Go ( Données 4Go / Journaux 4 Go )
Espace disponible 0 Mo.
Je suis toujours en train de faire une sauvegarde des journaux pour
récupérer de temps en temps qq Mo.
Je voulais savoir quel conseil me donneriez vous pour gérer une telle base
si sollicitée.
Les plans de maintenances dans l'interface Enteprise Manager sont ils
efficaces ?
Enfin voilà,
J'ai souvent des blocages au niveau utilisateurs car l'inscription des
journaux est saturé.
Oui il faut mettre en place des plans de maintenance. Faire un "shrink" des logs de la base lors de chaque backup full des informations (permet de réduire la taille du log). Il ne faut pas liasser SQL agrandir lui même les fichiers mais faire plutôt un peu de Capacity Planning et prévoyant une taille pour les données suffisante pour par exemple une semaine et agrandire par une procédure d'exploitation la taille des fichiers pendant des périodes "calmes".
Phil. ________________________________________________________ Philippe TROTIN Microsoft Services France http://www.microsoft.com/france "Emji" wrote in message news:
Bonjour la communauté, Bon, je suis un peu novice sur SQL et je vous expose donc mon interrogation.
J'ai une base qui est utilisé par une plate forme de scan de facture. Des factures sont numérisés par un scanner, puis vérifié par un module et enfin, traitées par les utilisatrices.
Toutes ces opérations alimentent une base que je nommerais "ehs". Le problème est le suivant :
La taille de la base augmente de 1 voire 2 Go par jour. Elle fait actuellement 8 Go ( Données 4Go / Journaux 4 Go ) Espace disponible 0 Mo.
Je suis toujours en train de faire une sauvegarde des journaux pour récupérer de temps en temps qq Mo.
Je voulais savoir quel conseil me donneriez vous pour gérer une telle base si sollicitée. Les plans de maintenances dans l'interface Enteprise Manager sont ils efficaces ? Enfin voilà, J'ai souvent des blocages au niveau utilisateurs car l'inscription des journaux est saturé.
Merci pour votre aide.
Rudi Bruchez
let Fri, 30 Jun 2006 08:15:02 -0700, Emji a écrit:
J'ai une base qui est utilisé par une plate forme de scan de facture. Des factures sont numérisés par un scanner, puis vérifié par un module et enfin, traitées par les utilisatrices.
Bonjour,
Une précision : comment ces factures scannées sont-elles stockées ? En tant qu'images en blob dans SQL Server, ou sont-elles reconnues d'abord en OCR ?
-- Rudi Bruchez - MCDBA http://www.babaluga.com/
let Fri, 30 Jun 2006 08:15:02 -0700, Emji a écrit:
J'ai une base qui est utilisé par une plate forme de scan de facture.
Des factures sont numérisés par un scanner, puis vérifié par un module et
enfin, traitées par les utilisatrices.
Bonjour,
Une précision : comment ces factures scannées sont-elles stockées ? En tant
qu'images en blob dans SQL Server, ou sont-elles reconnues d'abord en OCR ?
let Fri, 30 Jun 2006 08:15:02 -0700, Emji a écrit:
J'ai une base qui est utilisé par une plate forme de scan de facture. Des factures sont numérisés par un scanner, puis vérifié par un module et enfin, traitées par les utilisatrices.
Bonjour,
Une précision : comment ces factures scannées sont-elles stockées ? En tant qu'images en blob dans SQL Server, ou sont-elles reconnues d'abord en OCR ?
-- Rudi Bruchez - MCDBA http://www.babaluga.com/
Emji
Elles sont scannées en image puis un module " Interprete " effectue l'OCR. Ensuite, une équipe de 8 filles s'occupe de vérifier les factures interpretées via un autre module qui s'appelle " Verify ".
Nous traitons environs 7 000 factures par semaine. Ce matin, j'ai encore mon fichier journal qui a augmenté pour atteintre 8 go, ce fichier journal est pleins. Même lorsque j'effectue sa sauvegarde, il reste plein. J'ai 0 place de dispo dans la base. Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce fichier journal. Que puis faire ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
let Fri, 30 Jun 2006 08:15:02 -0700, Emji a écrit:
> J'ai une base qui est utilisé par une plate forme de scan de facture. > Des factures sont numérisés par un scanner, puis vérifié par un module et > enfin, traitées par les utilisatrices.
Bonjour,
Une précision : comment ces factures scannées sont-elles stockées ? En tant qu'images en blob dans SQL Server, ou sont-elles reconnues d'abord en OCR ?
-- Rudi Bruchez - MCDBA http://www.babaluga.com/
Elles sont scannées en image puis un module " Interprete " effectue l'OCR.
Ensuite, une équipe de 8 filles s'occupe de vérifier les factures
interpretées via un autre module qui s'appelle " Verify ".
Nous traitons environs 7 000 factures par semaine.
Ce matin, j'ai encore mon fichier journal qui a augmenté pour atteintre 8
go, ce fichier journal est pleins.
Même lorsque j'effectue sa sauvegarde, il reste plein.
J'ai 0 place de dispo dans la base.
Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce
fichier journal.
Que puis faire ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
let Fri, 30 Jun 2006 08:15:02 -0700, Emji a écrit:
> J'ai une base qui est utilisé par une plate forme de scan de facture.
> Des factures sont numérisés par un scanner, puis vérifié par un module et
> enfin, traitées par les utilisatrices.
Bonjour,
Une précision : comment ces factures scannées sont-elles stockées ? En tant
qu'images en blob dans SQL Server, ou sont-elles reconnues d'abord en OCR ?
Elles sont scannées en image puis un module " Interprete " effectue l'OCR. Ensuite, une équipe de 8 filles s'occupe de vérifier les factures interpretées via un autre module qui s'appelle " Verify ".
Nous traitons environs 7 000 factures par semaine. Ce matin, j'ai encore mon fichier journal qui a augmenté pour atteintre 8 go, ce fichier journal est pleins. Même lorsque j'effectue sa sauvegarde, il reste plein. J'ai 0 place de dispo dans la base. Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce fichier journal. Que puis faire ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
let Fri, 30 Jun 2006 08:15:02 -0700, Emji a écrit:
> J'ai une base qui est utilisé par une plate forme de scan de facture. > Des factures sont numérisés par un scanner, puis vérifié par un module et > enfin, traitées par les utilisatrices.
Bonjour,
Une précision : comment ces factures scannées sont-elles stockées ? En tant qu'images en blob dans SQL Server, ou sont-elles reconnues d'abord en OCR ?
-- Rudi Bruchez - MCDBA http://www.babaluga.com/
Rudi Bruchez
Emji a écrit:
Même lorsque j'effectue sa sauvegarde, il reste plein. J'ai 0 place de dispo dans la base. Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce fichier journal.
Si tu fais un backup log, et que le fichier journal reste plein, il y a peut-être une transaction ouvert depuis un certain temps. Lance DBCC OPENTRAN dans ta base pour vérifier ce point.
7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne stockes pas dans la base le résultat du scan en blob, avant traitement OCR, mais bien les données ensuite, dans une forme structurée ?
Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log ?
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Emji a écrit:
Même lorsque j'effectue sa sauvegarde, il reste plein.
J'ai 0 place de dispo dans la base.
Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce
fichier journal.
Si tu fais un backup log, et que le fichier journal reste plein, il y a
peut-être une transaction ouvert depuis un certain temps.
Lance DBCC OPENTRAN dans ta base pour vérifier ce point.
7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce
grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne
stockes pas dans la base le résultat du scan en blob, avant traitement OCR,
mais bien les données ensuite, dans une forme structurée ?
Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log
?
Même lorsque j'effectue sa sauvegarde, il reste plein. J'ai 0 place de dispo dans la base. Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce fichier journal.
Si tu fais un backup log, et que le fichier journal reste plein, il y a peut-être une transaction ouvert depuis un certain temps. Lance DBCC OPENTRAN dans ta base pour vérifier ce point.
7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne stockes pas dans la base le résultat du scan en blob, avant traitement OCR, mais bien les données ensuite, dans une forme structurée ?
Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log ?
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Emji
Oui j'ai une sauvegarde complète tous les soirs. J'ai lancé le dbcc OpenTran et je n'avais pas de transaction ouverte. J'ai ensuite effectué un backup log with truncate_only, opuis j'ai fait un shrink de mes journaux. Maintenant j'ai 3500 utilisé pour la partie data 16 Mo pour la partie journaux.
J'ai les options suivantes sur la base
Model = simple Auto Update stat = coché Détection pages endomagées = coché Réduction automatique = coché Créer automatiquement les stats = coché
Dans l'onglet General Fichir à croissance automatique de coché avec uen taille limite définie pour les données et les journaux.
Cela te semble t-il cohérent ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Emji a écrit:
> Même lorsque j'effectue sa sauvegarde, il reste plein. > J'ai 0 place de dispo dans la base. > Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce > fichier journal.
Si tu fais un backup log, et que le fichier journal reste plein, il y a peut-être une transaction ouvert depuis un certain temps. Lance DBCC OPENTRAN dans ta base pour vérifier ce point.
7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne stockes pas dans la base le résultat du scan en blob, avant traitement OCR, mais bien les données ensuite, dans une forme structurée ?
Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log ?
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
Oui j'ai une sauvegarde complète tous les soirs.
J'ai lancé le dbcc OpenTran et je n'avais pas de transaction ouverte.
J'ai ensuite effectué un backup log with truncate_only, opuis j'ai fait un
shrink de mes journaux.
Maintenant j'ai
3500 utilisé pour la partie data
16 Mo pour la partie journaux.
J'ai les options suivantes sur la base
Model = simple
Auto Update stat = coché
Détection pages endomagées = coché
Réduction automatique = coché
Créer automatiquement les stats = coché
Dans l'onglet General
Fichir à croissance automatique de coché avec uen taille limite définie pour
les données et les journaux.
Cela te semble t-il cohérent ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Emji a écrit:
> Même lorsque j'effectue sa sauvegarde, il reste plein.
> J'ai 0 place de dispo dans la base.
> Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce
> fichier journal.
Si tu fais un backup log, et que le fichier journal reste plein, il y a
peut-être une transaction ouvert depuis un certain temps.
Lance DBCC OPENTRAN dans ta base pour vérifier ce point.
7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce
grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne
stockes pas dans la base le résultat du scan en blob, avant traitement OCR,
mais bien les données ensuite, dans une forme structurée ?
Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log
?
Oui j'ai une sauvegarde complète tous les soirs. J'ai lancé le dbcc OpenTran et je n'avais pas de transaction ouverte. J'ai ensuite effectué un backup log with truncate_only, opuis j'ai fait un shrink de mes journaux. Maintenant j'ai 3500 utilisé pour la partie data 16 Mo pour la partie journaux.
J'ai les options suivantes sur la base
Model = simple Auto Update stat = coché Détection pages endomagées = coché Réduction automatique = coché Créer automatiquement les stats = coché
Dans l'onglet General Fichir à croissance automatique de coché avec uen taille limite définie pour les données et les journaux.
Cela te semble t-il cohérent ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
Emji a écrit:
> Même lorsque j'effectue sa sauvegarde, il reste plein. > J'ai 0 place de dispo dans la base. > Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce > fichier journal.
Si tu fais un backup log, et que le fichier journal reste plein, il y a peut-être une transaction ouvert depuis un certain temps. Lance DBCC OPENTRAN dans ta base pour vérifier ce point.
7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne stockes pas dans la base le résultat du scan en blob, avant traitement OCR, mais bien les données ensuite, dans une forme structurée ?
Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log ?
-- Rudi Bruchez, MCDBA http://www.babaluga.com/
mathias
Bonjour, le modèle de recovery Simple et backup log with truncate_only sont dangereux pour ta base. Tu n'a plus la possibilité de restaurer (ou sauvegarder) tes journaux de transaction. Dommage de perdre une journée de factures à cause d'un manuqe d'espace disque.
Cordialement Mathias
"Emji" a écrit :
Oui j'ai une sauvegarde complète tous les soirs. J'ai lancé le dbcc OpenTran et je n'avais pas de transaction ouverte. J'ai ensuite effectué un backup log with truncate_only, opuis j'ai fait un shrink de mes journaux. Maintenant j'ai 3500 utilisé pour la partie data 16 Mo pour la partie journaux.
J'ai les options suivantes sur la base
Model = simple Auto Update stat = coché Détection pages endomagées = coché Réduction automatique = coché Créer automatiquement les stats = coché
Dans l'onglet General Fichir à croissance automatique de coché avec uen taille limite définie pour les données et les journaux.
Cela te semble t-il cohérent ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
> Emji a écrit: > > > Même lorsque j'effectue sa sauvegarde, il reste plein. > > J'ai 0 place de dispo dans la base. > > Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce > > fichier journal. > > Si tu fais un backup log, et que le fichier journal reste plein, il y a > peut-être une transaction ouvert depuis un certain temps. > Lance DBCC OPENTRAN dans ta base pour vérifier ce point. > > 7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce > grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne > stockes pas dans la base le résultat du scan en blob, avant traitement OCR, > mais bien les données ensuite, dans une forme structurée ? > > Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log > ? > > -- > Rudi Bruchez, MCDBA > http://www.babaluga.com/ >
Bonjour,
le modèle de recovery Simple et backup log with truncate_only sont dangereux
pour ta base.
Tu n'a plus la possibilité de restaurer (ou sauvegarder) tes journaux de
transaction.
Dommage de perdre une journée de factures à cause d'un manuqe d'espace disque.
Cordialement
Mathias
"Emji" a écrit :
Oui j'ai une sauvegarde complète tous les soirs.
J'ai lancé le dbcc OpenTran et je n'avais pas de transaction ouverte.
J'ai ensuite effectué un backup log with truncate_only, opuis j'ai fait un
shrink de mes journaux.
Maintenant j'ai
3500 utilisé pour la partie data
16 Mo pour la partie journaux.
J'ai les options suivantes sur la base
Model = simple
Auto Update stat = coché
Détection pages endomagées = coché
Réduction automatique = coché
Créer automatiquement les stats = coché
Dans l'onglet General
Fichir à croissance automatique de coché avec uen taille limite définie pour
les données et les journaux.
Cela te semble t-il cohérent ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
> Emji a écrit:
>
> > Même lorsque j'effectue sa sauvegarde, il reste plein.
> > J'ai 0 place de dispo dans la base.
> > Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce
> > fichier journal.
>
> Si tu fais un backup log, et que le fichier journal reste plein, il y a
> peut-être une transaction ouvert depuis un certain temps.
> Lance DBCC OPENTRAN dans ta base pour vérifier ce point.
>
> 7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce
> grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne
> stockes pas dans la base le résultat du scan en blob, avant traitement OCR,
> mais bien les données ensuite, dans une forme structurée ?
>
> Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log
> ?
>
> --
> Rudi Bruchez, MCDBA
> http://www.babaluga.com/
>
Bonjour, le modèle de recovery Simple et backup log with truncate_only sont dangereux pour ta base. Tu n'a plus la possibilité de restaurer (ou sauvegarder) tes journaux de transaction. Dommage de perdre une journée de factures à cause d'un manuqe d'espace disque.
Cordialement Mathias
"Emji" a écrit :
Oui j'ai une sauvegarde complète tous les soirs. J'ai lancé le dbcc OpenTran et je n'avais pas de transaction ouverte. J'ai ensuite effectué un backup log with truncate_only, opuis j'ai fait un shrink de mes journaux. Maintenant j'ai 3500 utilisé pour la partie data 16 Mo pour la partie journaux.
J'ai les options suivantes sur la base
Model = simple Auto Update stat = coché Détection pages endomagées = coché Réduction automatique = coché Créer automatiquement les stats = coché
Dans l'onglet General Fichir à croissance automatique de coché avec uen taille limite définie pour les données et les journaux.
Cela te semble t-il cohérent ?
"Rudi Bruchez" <"rudi#nospam#[at]babaluga" a écrit :
> Emji a écrit: > > > Même lorsque j'effectue sa sauvegarde, il reste plein. > > J'ai 0 place de dispo dans la base. > > Je ne peux pas effectuer une sauvegarde complète car ca bloque à cause de ce > > fichier journal. > > Si tu fais un backup log, et que le fichier journal reste plein, il y a > peut-être une transaction ouvert depuis un certain temps. > Lance DBCC OPENTRAN dans ta base pour vérifier ce point. > > 7000 factures par semaine c'est peu, et ça ne justifie pas vraiment ce > grossissement. Nous sommes d'accord, pour reprendre ma question, que tu ne > stockes pas dans la base le résultat du scan en blob, avant traitement OCR, > mais bien les données ensuite, dans une forme structurée ? > > Quelle est ta statégie de backup ? Fais-tu régulièrement des backups de log > ? > > -- > Rudi Bruchez, MCDBA > http://www.babaluga.com/ >
