J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild
index task"
voici l'insulte :
Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD
WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF,
IGNORE_DUP_KEY = OFF, ONLINE = ON )
" failed with the following error: "Online index operations can only
be performed in Enterprise edition of SQL Server.". Possible failure
reasons: Problems with the query, "ResultSet" property not set
correctly, parameters not set correctly, or connection not established
correctly.
j'ai une version SQL 2005 standard, dois je prendre en compte cette
ligne " Online index operations can only be performed in Enterprise
edition of SQL Server " et si c'est le cas, dans la version standard
comment fait on cette manipulation ?
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
twingo
On 9 déc, 16:10, wrote:
Bonjour,
J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild index task"
voici l'insulte :
Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = ON ) " failed with the following error: "Online index operations can only be performed in Enterprise edition of SQL Server.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
j'ai une version SQL 2005 standard, dois je prendre en compte cette ligne " Online index operations can only be performed in Enterprise edition of SQL Server " et si c'est le cas, dans la version standard comment fait on cette manipulation ?
D'avance merci,
T
Finalement je m'auto répond, il s'agit d'un probleme d'espace disque. T
On 9 déc, 16:10, twi...@ifrance.com wrote:
Bonjour,
J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild
index task"
voici l'insulte :
Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD
WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF,
IGNORE_DUP_KEY = OFF, ONLINE = ON )
" failed with the following error: "Online index operations can only
be performed in Enterprise edition of SQL Server.". Possible failure
reasons: Problems with the query, "ResultSet" property not set
correctly, parameters not set correctly, or connection not established
correctly.
j'ai une version SQL 2005 standard, dois je prendre en compte cette
ligne " Online index operations can only be performed in Enterprise
edition of SQL Server " et si c'est le cas, dans la version standard
comment fait on cette manipulation ?
D'avance merci,
T
Finalement je m'auto répond, il s'agit d'un probleme d'espace disque.
T
J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild index task"
voici l'insulte :
Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = ON ) " failed with the following error: "Online index operations can only be performed in Enterprise edition of SQL Server.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
j'ai une version SQL 2005 standard, dois je prendre en compte cette ligne " Online index operations can only be performed in Enterprise edition of SQL Server " et si c'est le cas, dans la version standard comment fait on cette manipulation ?
D'avance merci,
T
Finalement je m'auto répond, il s'agit d'un probleme d'espace disque. T
Fred BROUARD
a écrit :
Bonjour,
J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild index task"
voici l'insulte :
Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = ON ) " failed with the following error: "Online index operations can only be performed in Enterprise edition of SQL Server.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
j'ai une version SQL 2005 standard, dois je prendre en compte cette ligne " Online index operations can only be performed in Enterprise edition of SQL Server " et si c'est le cas, dans la version standard comment fait on cette manipulation ?
D'avance merci,
T
C'est une limitation de la version Entreprise. Cette fonctionnalité n'est disponible que dans la version Enterprise. C'est d'ailleurs assez normal, car l'indexation ONLINE est très consommatrice de ressources en tout genre, dont processeur. Je la déconseille si vous n'avez pas au moins un octo processeur, car le bit de l'indexation ONLINE est de ré indexer sans perte d'index donc en pleine production, pour les bases de données qui fonctionnent 24h/24 7j/7 à pleine charge !
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
twingo@ifrance.com a écrit :
Bonjour,
J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild
index task"
voici l'insulte :
Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD
WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF,
IGNORE_DUP_KEY = OFF, ONLINE = ON )
" failed with the following error: "Online index operations can only
be performed in Enterprise edition of SQL Server.". Possible failure
reasons: Problems with the query, "ResultSet" property not set
correctly, parameters not set correctly, or connection not established
correctly.
j'ai une version SQL 2005 standard, dois je prendre en compte cette
ligne " Online index operations can only be performed in Enterprise
edition of SQL Server " et si c'est le cas, dans la version standard
comment fait on cette manipulation ?
D'avance merci,
T
C'est une limitation de la version Entreprise. Cette fonctionnalité
n'est disponible que dans la version Enterprise. C'est d'ailleurs assez
normal, car l'indexation ONLINE est très consommatrice de ressources en
tout genre, dont processeur. Je la déconseille si vous n'avez pas au
moins un octo processeur, car le bit de l'indexation ONLINE est de ré
indexer sans perte d'index donc en pleine production, pour les bases de
données qui fonctionnent 24h/24 7j/7 à pleine charge !
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild index task"
voici l'insulte :
Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = ON ) " failed with the following error: "Online index operations can only be performed in Enterprise edition of SQL Server.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
j'ai une version SQL 2005 standard, dois je prendre en compte cette ligne " Online index operations can only be performed in Enterprise edition of SQL Server " et si c'est le cas, dans la version standard comment fait on cette manipulation ?
D'avance merci,
T
C'est une limitation de la version Entreprise. Cette fonctionnalité n'est disponible que dans la version Enterprise. C'est d'ailleurs assez normal, car l'indexation ONLINE est très consommatrice de ressources en tout genre, dont processeur. Je la déconseille si vous n'avez pas au moins un octo processeur, car le bit de l'indexation ONLINE est de ré indexer sans perte d'index donc en pleine production, pour les bases de données qui fonctionnent 24h/24 7j/7 à pleine charge !
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
twingo
On 10 déc, 16:10, Fred BROUARD wrote:
a écrit :
> Bonjour,
> J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild > index task"
> voici l'insulte :
> Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD > WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, > ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, > IGNORE_DUP_KEY = OFF, ONLINE = ON ) > " failed with the following error: "Online index operations can only > be performed in Enterprise edition of SQL Server.". Possible failure > reasons: Problems with the query, "ResultSet" property not set > correctly, parameters not set correctly, or connection not established > correctly.
> j'ai une version SQL 2005 standard, dois je prendre en compte cette > ligne " Online index operations can only be performed in Enterprise > edition of SQL Server " et si c'est le cas, dans la version standard > comment fait on cette manipulation ?
> D'avance merci,
> T
C'est une limitation de la version Entreprise. Cette fonctionnalité n'est disponible que dans la version Enterprise. C'est d'ailleurs assez normal, car l'indexation ONLINE est très consommatrice de ressources en tout genre, dont processeur. Je la déconseille si vous n'avez pas au moins un octo processeur, car le bit de l'indexation ONLINE est de ré indexer sans perte d'index donc en pleine production, pour les bases de données qui fonctionnent 24h/24 7j/7 à pleine charge !
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langag e SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez. com Audit, conseil, expertise, formation, modélisation, tuning, optimisatio n ***********************http://www.sqlspot.com*************************- M asquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour Frédéric,
Merci pour votre réponse. néanmoins, avec un espace disque consequent et malgré ma version standard, cette fonctionnalité est opérationnelle. En revanche, nos plans de maintenance sont fait le soir pendant que tout le monde dors (les bases sont européennes pour l'instant) donc pas de soucie de décallage horraire. Quel est selon vous le best practise d'un plan de maintenance ? Voici a quoi ressemble le mien : Dabord le backup : Check database Integrity task puis Backup Database task, puis maintenance cleanup task. Seconde étape : Check database Integrity task puis Rebuild index task (celui la même qui a besoin d'une grosse ressource espace disque).
Votre avis ?
T
On 10 déc, 16:10, Fred BROUARD <broua...@club-internet.fr> wrote:
twi...@ifrance.com a écrit :
> Bonjour,
> J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild
> index task"
> voici l'insulte :
> Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD
> WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
> ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF,
> IGNORE_DUP_KEY = OFF, ONLINE = ON )
> " failed with the following error: "Online index operations can only
> be performed in Enterprise edition of SQL Server.". Possible failure
> reasons: Problems with the query, "ResultSet" property not set
> correctly, parameters not set correctly, or connection not established
> correctly.
> j'ai une version SQL 2005 standard, dois je prendre en compte cette
> ligne " Online index operations can only be performed in Enterprise
> edition of SQL Server " et si c'est le cas, dans la version standard
> comment fait on cette manipulation ?
> D'avance merci,
> T
C'est une limitation de la version Entreprise. Cette fonctionnalité
n'est disponible que dans la version Enterprise. C'est d'ailleurs assez
normal, car l'indexation ONLINE est très consommatrice de ressources en
tout genre, dont processeur. Je la déconseille si vous n'avez pas au
moins un octo processeur, car le bit de l'indexation ONLINE est de ré
indexer sans perte d'index donc en pleine production, pour les bases de
données qui fonctionnent 24h/24 7j/7 à pleine charge !
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langag e SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez. com
Audit, conseil, expertise, formation, modélisation, tuning, optimisatio n
***********************http://www.sqlspot.com*************************- M asquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour Frédéric,
Merci pour votre réponse.
néanmoins, avec un espace disque consequent et malgré ma version
standard, cette fonctionnalité est opérationnelle.
En revanche, nos plans de maintenance sont fait le soir pendant que
tout le monde dors (les bases sont européennes pour l'instant) donc
pas de soucie de décallage horraire.
Quel est selon vous le best practise d'un plan de maintenance ?
Voici a quoi ressemble le mien :
Dabord le backup : Check database Integrity task puis Backup Database
task, puis maintenance cleanup task.
Seconde étape :
Check database Integrity task puis Rebuild index task (celui la même
qui a besoin d'une grosse ressource espace disque).
> J'ai un message d'erreur lors d'un plan de maintenance sur le "rebuild > index task"
> voici l'insulte :
> Executing the query "ALTER INDEX [aaccod] ON [dbo].[aaccod] REBUILD > WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, > ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, SORT_IN_TEMPDB = OFF, > IGNORE_DUP_KEY = OFF, ONLINE = ON ) > " failed with the following error: "Online index operations can only > be performed in Enterprise edition of SQL Server.". Possible failure > reasons: Problems with the query, "ResultSet" property not set > correctly, parameters not set correctly, or connection not established > correctly.
> j'ai une version SQL 2005 standard, dois je prendre en compte cette > ligne " Online index operations can only be performed in Enterprise > edition of SQL Server " et si c'est le cas, dans la version standard > comment fait on cette manipulation ?
> D'avance merci,
> T
C'est une limitation de la version Entreprise. Cette fonctionnalité n'est disponible que dans la version Enterprise. C'est d'ailleurs assez normal, car l'indexation ONLINE est très consommatrice de ressources en tout genre, dont processeur. Je la déconseille si vous n'avez pas au moins un octo processeur, car le bit de l'indexation ONLINE est de ré indexer sans perte d'index donc en pleine production, pour les bases de données qui fonctionnent 24h/24 7j/7 à pleine charge !
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langag e SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez. com Audit, conseil, expertise, formation, modélisation, tuning, optimisatio n ***********************http://www.sqlspot.com*************************- M asquer le texte des messages précédents -
- Afficher le texte des messages précédents -
Bonjour Frédéric,
Merci pour votre réponse. néanmoins, avec un espace disque consequent et malgré ma version standard, cette fonctionnalité est opérationnelle. En revanche, nos plans de maintenance sont fait le soir pendant que tout le monde dors (les bases sont européennes pour l'instant) donc pas de soucie de décallage horraire. Quel est selon vous le best practise d'un plan de maintenance ? Voici a quoi ressemble le mien : Dabord le backup : Check database Integrity task puis Backup Database task, puis maintenance cleanup task. Seconde étape : Check database Integrity task puis Rebuild index task (celui la même qui a besoin d'une grosse ressource espace disque).
Votre avis ?
T
Fred BROUARD
Bonjour,
a écrit :
Bonjour Frédéric,
Merci pour votre réponse. néanmoins, avec un espace disque consequent et malgré ma version standard, cette fonctionnalité est opérationnelle.
je pense que ce n'est pas le cas. Il doit peut être la prendre en considération (et j'en doute), mais pas le faire en //
En revanche, nos plans de maintenance sont fait le soir pendant que tout le monde dors (les bases sont européennes pour l'instant) donc pas de soucie de décallage horraire. Quel est selon vous le best practise d'un plan de maintenance ? Voici a quoi ressemble le mien : Dabord le backup : Check database Integrity task puis Backup Database task, puis maintenance cleanup task. Seconde étape : Check database Integrity task puis Rebuild index task (celui la même qui a besoin d'une grosse ressource espace disque).
Tout dépend de la volumétrie des données. Si vous n'avez que quelques Go, alors OK, si vous commencez à plus de 100 Go il va falloir en faire le minimum. par exemple de réindexer que les index fragmentés. Vous pouvez aussi pour accélérer la chose, passer en mode de recouvrement simple le temps de faire la réindexation. Pour ma part je ferais une sauvegarde avant de voir si la base est intégre. puis après toutes les op de maintenance. Si votre abse est grosse avec différentielle... Etc.
Donc sans connaitre la taille je ne peut vous en dire plus !
En revanche surtout pas de cleanup. C'est de la connerie pure ! Lisez que que je dis dans ce blog http://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fichiers_et_t Paragraphe "Pire ! C'est possible..."
En règle général les plans de maintenance tout fait ne font rien de bien. C'est pour les gens qui passent d'Access à SQL Server et ne veulent pas se poser de questions mais ne demande pas non plus de perf.
Votre avis ?
T
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
Bonjour,
twingo@ifrance.com a écrit :
Bonjour Frédéric,
Merci pour votre réponse.
néanmoins, avec un espace disque consequent et malgré ma version
standard, cette fonctionnalité est opérationnelle.
je pense que ce n'est pas le cas. Il doit peut être la prendre en
considération (et j'en doute), mais pas le faire en //
En revanche, nos plans de maintenance sont fait le soir pendant que
tout le monde dors (les bases sont européennes pour l'instant) donc
pas de soucie de décallage horraire.
Quel est selon vous le best practise d'un plan de maintenance ?
Voici a quoi ressemble le mien :
Dabord le backup : Check database Integrity task puis Backup Database
task, puis maintenance cleanup task.
Seconde étape :
Check database Integrity task puis Rebuild index task (celui la même
qui a besoin d'une grosse ressource espace disque).
Tout dépend de la volumétrie des données. Si vous n'avez que quelques
Go, alors OK, si vous commencez à plus de 100 Go il va falloir en faire
le minimum. par exemple de réindexer que les index fragmentés. Vous
pouvez aussi pour accélérer la chose, passer en mode de recouvrement
simple le temps de faire la réindexation.
Pour ma part je ferais une sauvegarde avant de voir si la base est
intégre. puis après toutes les op de maintenance. Si votre abse est
grosse avec différentielle...
Etc.
Donc sans connaitre la taille je ne peut vous en dire plus !
En revanche surtout pas de cleanup. C'est de la connerie pure !
Lisez que que je dis dans ce blog
http://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fichiers_et_t
Paragraphe "Pire ! C'est possible..."
En règle général les plans de maintenance tout fait ne font rien de
bien. C'est pour les gens qui passent d'Access à SQL Server et ne
veulent pas se poser de questions mais ne demande pas non plus de perf.
Votre avis ?
T
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Merci pour votre réponse. néanmoins, avec un espace disque consequent et malgré ma version standard, cette fonctionnalité est opérationnelle.
je pense que ce n'est pas le cas. Il doit peut être la prendre en considération (et j'en doute), mais pas le faire en //
En revanche, nos plans de maintenance sont fait le soir pendant que tout le monde dors (les bases sont européennes pour l'instant) donc pas de soucie de décallage horraire. Quel est selon vous le best practise d'un plan de maintenance ? Voici a quoi ressemble le mien : Dabord le backup : Check database Integrity task puis Backup Database task, puis maintenance cleanup task. Seconde étape : Check database Integrity task puis Rebuild index task (celui la même qui a besoin d'une grosse ressource espace disque).
Tout dépend de la volumétrie des données. Si vous n'avez que quelques Go, alors OK, si vous commencez à plus de 100 Go il va falloir en faire le minimum. par exemple de réindexer que les index fragmentés. Vous pouvez aussi pour accélérer la chose, passer en mode de recouvrement simple le temps de faire la réindexation. Pour ma part je ferais une sauvegarde avant de voir si la base est intégre. puis après toutes les op de maintenance. Si votre abse est grosse avec différentielle... Etc.
Donc sans connaitre la taille je ne peut vous en dire plus !
En revanche surtout pas de cleanup. C'est de la connerie pure ! Lisez que que je dis dans ce blog http://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fichiers_et_t Paragraphe "Pire ! C'est possible..."
En règle général les plans de maintenance tout fait ne font rien de bien. C'est pour les gens qui passent d'Access à SQL Server et ne veulent pas se poser de questions mais ne demande pas non plus de perf.
Votre avis ?
T
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
twingo
Re bonjour,
je pense que ce n'est pas le cas. Il doit peut être la prendre en considération (et j'en doute), mais pas le faire en //
j'ai lancé cette option sur un serveur avec un espace disque adequat, il ne m'a pas insulté et m'a lancé fier un "Succes Job"?
Donc sans connaitre la taille je ne peut vous en dire plus !
"mes" bases vont de 1 a 5giga environ, et tendent a grossir (base comptable)
En revanche surtout pas de cleanup. C'est de la connerie pure ! Lisez que que je dis dans ce bloghttp://blog.developpez.com/sqlpro?title =fragmentation_physique_des_fi... Paragraphe "Pire ! C'est possible..."
Je ne comprend pas votre alerte. le cleanup ne fait qu'un cleanup des .bak au bout de X jours. On garde deux jours de sauvegarde sur disque, et bien plus avec un logiciel de sauvegarde.
En règle général les plans de maintenance tout fait ne font rien de bien. C'est pour les gens qui passent d'Access à SQL Server et ne veulent pas se poser de questions mais ne demande pas non plus de perf.
Nous on veux de la perf :)
T
Re bonjour,
je pense que ce n'est pas le cas. Il doit peut être la prendre en
considération (et j'en doute), mais pas le faire en //
j'ai lancé cette option sur un serveur avec un espace disque adequat,
il ne m'a pas insulté et m'a lancé fier un "Succes Job"?
Donc sans connaitre la taille je ne peut vous en dire plus !
"mes" bases vont de 1 a 5giga environ, et tendent a grossir (base
comptable)
En revanche surtout pas de cleanup. C'est de la connerie pure !
Lisez que que je dis dans ce bloghttp://blog.developpez.com/sqlpro?title =fragmentation_physique_des_fi...
Paragraphe "Pire ! C'est possible..."
Je ne comprend pas votre alerte. le cleanup ne fait qu'un cleanup
des .bak au bout de X jours. On garde deux jours de sauvegarde sur
disque, et bien plus avec un logiciel de sauvegarde.
En règle général les plans de maintenance tout fait ne font rien de
bien. C'est pour les gens qui passent d'Access à SQL Server et ne
veulent pas se poser de questions mais ne demande pas non plus de perf.
je pense que ce n'est pas le cas. Il doit peut être la prendre en considération (et j'en doute), mais pas le faire en //
j'ai lancé cette option sur un serveur avec un espace disque adequat, il ne m'a pas insulté et m'a lancé fier un "Succes Job"?
Donc sans connaitre la taille je ne peut vous en dire plus !
"mes" bases vont de 1 a 5giga environ, et tendent a grossir (base comptable)
En revanche surtout pas de cleanup. C'est de la connerie pure ! Lisez que que je dis dans ce bloghttp://blog.developpez.com/sqlpro?title =fragmentation_physique_des_fi... Paragraphe "Pire ! C'est possible..."
Je ne comprend pas votre alerte. le cleanup ne fait qu'un cleanup des .bak au bout de X jours. On garde deux jours de sauvegarde sur disque, et bien plus avec un logiciel de sauvegarde.
En règle général les plans de maintenance tout fait ne font rien de bien. C'est pour les gens qui passent d'Access à SQL Server et ne veulent pas se poser de questions mais ne demande pas non plus de perf.
Nous on veux de la perf :)
T
Fred BROUARD
a écrit :
Re bonjour,
je pense que ce n'est pas le cas. Il doit peut être la prendre en considération (et j'en doute), mais pas le faire en //
j'ai lancé cette option sur un serveur avec un espace disque adequat, il ne m'a pas insulté et m'a lancé fier un "Succes Job"?
Donc sans connaitre la taille je ne peut vous en dire plus !
"mes" bases vont de 1 a 5giga environ, et tendent a grossir (base comptable)
En revanche surtout pas de cleanup. C'est de la connerie pure ! Lisez que que je dis dans ce bloghttp://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fi... Paragraphe "Pire ! C'est possible..."
Je ne comprend pas votre alerte. le cleanup ne fait qu'un cleanup des .bak au bout de X jours. On garde deux jours de sauvegarde sur disque, et bien plus avec un logiciel de sauvegarde.
pardon eje croyais a un SHRINK
En règle général les plans de maintenance tout fait ne font rien de bien. C'est pour les gens qui passent d'Access à SQL Server et ne veulent pas se poser de questions mais ne demande pas non plus de perf.
Nous on veux de la perf :)
donc à la mano !
A +
T
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
twingo@ifrance.com a écrit :
Re bonjour,
je pense que ce n'est pas le cas. Il doit peut être la prendre en
considération (et j'en doute), mais pas le faire en //
j'ai lancé cette option sur un serveur avec un espace disque adequat,
il ne m'a pas insulté et m'a lancé fier un "Succes Job"?
Donc sans connaitre la taille je ne peut vous en dire plus !
"mes" bases vont de 1 a 5giga environ, et tendent a grossir (base
comptable)
En revanche surtout pas de cleanup. C'est de la connerie pure !
Lisez que que je dis dans ce bloghttp://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fi...
Paragraphe "Pire ! C'est possible..."
Je ne comprend pas votre alerte. le cleanup ne fait qu'un cleanup
des .bak au bout de X jours. On garde deux jours de sauvegarde sur
disque, et bien plus avec un logiciel de sauvegarde.
pardon eje croyais a un SHRINK
En règle général les plans de maintenance tout fait ne font rien de
bien. C'est pour les gens qui passent d'Access à SQL Server et ne
veulent pas se poser de questions mais ne demande pas non plus de perf.
Nous on veux de la perf :)
donc à la mano !
A +
T
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
je pense que ce n'est pas le cas. Il doit peut être la prendre en considération (et j'en doute), mais pas le faire en //
j'ai lancé cette option sur un serveur avec un espace disque adequat, il ne m'a pas insulté et m'a lancé fier un "Succes Job"?
Donc sans connaitre la taille je ne peut vous en dire plus !
"mes" bases vont de 1 a 5giga environ, et tendent a grossir (base comptable)
En revanche surtout pas de cleanup. C'est de la connerie pure ! Lisez que que je dis dans ce bloghttp://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fi... Paragraphe "Pire ! C'est possible..."
Je ne comprend pas votre alerte. le cleanup ne fait qu'un cleanup des .bak au bout de X jours. On garde deux jours de sauvegarde sur disque, et bien plus avec un logiciel de sauvegarde.
pardon eje croyais a un SHRINK
En règle général les plans de maintenance tout fait ne font rien de bien. C'est pour les gens qui passent d'Access à SQL Server et ne veulent pas se poser de questions mais ne demande pas non plus de perf.
Nous on veux de la perf :)
donc à la mano !
A +
T
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation *********************** http://www.sqlspot.com *************************
