Olivier a écrit :Est-ce que tu es sur que ta solution marche bien, car tu sais que les
statistiques sont aussi stockées dans la même tables (sysindexes) avec le
type U il me semble.
Donc effectivement c'ets interressant, mais est-ce que défragmenter les
stats est bien utile ?
effectivement il faut éviter les WA_Sys... dans ce cas faire un fitre sur
la table sysindexes avec status & 64 = 64
De plus le defrag ne remet pas à jour les index. Il faut donc faire un
update stats derrière !
A +
Merci.
"Romelard Fabrice [MVP]" a écrit :Bonjour,
Sur les spécification de Fred, j'ai modifié la solution que j'avais
proposé.
Voici donc une procédure stockée permettant de faire une défragmentation
et non une reconstruction des index.
- http://sqlfr.com/code.aspx?ID6635
N'hésitez pas à me signaler tout problème en cas.
--
Cordialement.
Romelard Fabrice [MVP]
"Olivier" a écrit dans le message de
news:J'ai des index qui sont fragmenté et ce jusqu'a 30% (table pas trés
grosse).
Est-ce que cette fragmentation est vraiment contre performantes sur des
gros
traitement de recherche d'enreg ?
Je compte executer un dbreindex toute les nuits pour pallier à ce
problème,
car j'ai remarqué que le dbreindex était assez efficace pour
réorganiser les
index.
Est-ce que c'est la meilleur méthode, car je pourrais faire un create
index
with existing, mais je ne sais pas si cela ca être plus efficace.
Merci.
--
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.datasapiens.com ***********************
Olivier a écrit :
Est-ce que tu es sur que ta solution marche bien, car tu sais que les
statistiques sont aussi stockées dans la même tables (sysindexes) avec le
type U il me semble.
Donc effectivement c'ets interressant, mais est-ce que défragmenter les
stats est bien utile ?
effectivement il faut éviter les WA_Sys... dans ce cas faire un fitre sur
la table sysindexes avec status & 64 = 64
De plus le defrag ne remet pas à jour les index. Il faut donc faire un
update stats derrière !
A +
Merci.
"Romelard Fabrice [MVP]" a écrit :
Bonjour,
Sur les spécification de Fred, j'ai modifié la solution que j'avais
proposé.
Voici donc une procédure stockée permettant de faire une défragmentation
et non une reconstruction des index.
- http://sqlfr.com/code.aspx?ID6635
N'hésitez pas à me signaler tout problème en cas.
--
Cordialement.
Romelard Fabrice [MVP]
"Olivier" <Olivier@discussions.microsoft.com> a écrit dans le message de
news: 0B14A4F7-8AD6-4C2B-85AD-4487EE3B3E6F@microsoft.com...
J'ai des index qui sont fragmenté et ce jusqu'a 30% (table pas trés
grosse).
Est-ce que cette fragmentation est vraiment contre performantes sur des
gros
traitement de recherche d'enreg ?
Je compte executer un dbreindex toute les nuits pour pallier à ce
problème,
car j'ai remarqué que le dbreindex était assez efficace pour
réorganiser les
index.
Est-ce que c'est la meilleur méthode, car je pourrais faire un create
index
with existing, mais je ne sais pas si cela ca être plus efficace.
Merci.
--
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.datasapiens.com ***********************
Olivier a écrit :Est-ce que tu es sur que ta solution marche bien, car tu sais que les
statistiques sont aussi stockées dans la même tables (sysindexes) avec le
type U il me semble.
Donc effectivement c'ets interressant, mais est-ce que défragmenter les
stats est bien utile ?
effectivement il faut éviter les WA_Sys... dans ce cas faire un fitre sur
la table sysindexes avec status & 64 = 64
De plus le defrag ne remet pas à jour les index. Il faut donc faire un
update stats derrière !
A +
Merci.
"Romelard Fabrice [MVP]" a écrit :Bonjour,
Sur les spécification de Fred, j'ai modifié la solution que j'avais
proposé.
Voici donc une procédure stockée permettant de faire une défragmentation
et non une reconstruction des index.
- http://sqlfr.com/code.aspx?ID6635
N'hésitez pas à me signaler tout problème en cas.
--
Cordialement.
Romelard Fabrice [MVP]
"Olivier" a écrit dans le message de
news:J'ai des index qui sont fragmenté et ce jusqu'a 30% (table pas trés
grosse).
Est-ce que cette fragmentation est vraiment contre performantes sur des
gros
traitement de recherche d'enreg ?
Je compte executer un dbreindex toute les nuits pour pallier à ce
problème,
car j'ai remarqué que le dbreindex était assez efficace pour
réorganiser les
index.
Est-ce que c'est la meilleur méthode, car je pourrais faire un create
index
with existing, mais je ne sais pas si cela ca être plus efficace.
Merci.
--
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.datasapiens.com ***********************
Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :
> Bonsoir,
>
> La source en question a été modifiée afin d'intégrer les remontées
> spécifiées :
> - http://sqlfr.com/code.aspx?ID6635
>
> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
> me provoque des erreurs comme par exemple :
>
> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
> qui remontent :
> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
> Impossible de trouver un index nommé 'restorefile' dans la table
> 'restorefile'.
> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
> contactez l'administrateur du système.
>
> ou encore :
> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
> qui remontent :
> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
> Impossible de trouver un index nommé 'restorefilegroup' dans la table
> 'restorefilegroup'.
> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
> contactez l'administrateur du système.
>
>
> J'en ai plusieurs comme ca uniquement sur ces deux bases.
> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
> suis preneur ?
>
--
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.datasapiens.com ***********************
dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :
> Bonsoir,
>
> La source en question a été modifiée afin d'intégrer les remontées
> spécifiées :
> - http://sqlfr.com/code.aspx?ID6635
>
> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
> me provoque des erreurs comme par exemple :
>
> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
> qui remontent :
> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
> Impossible de trouver un index nommé 'restorefile' dans la table
> 'restorefile'.
> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
> contactez l'administrateur du système.
>
> ou encore :
> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
> qui remontent :
> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
> Impossible de trouver un index nommé 'restorefilegroup' dans la table
> 'restorefilegroup'.
> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
> contactez l'administrateur du système.
>
>
> J'en ai plusieurs comme ca uniquement sur ces deux bases.
> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
> suis preneur ?
>
--
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.datasapiens.com ***********************
dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :
> Bonsoir,
>
> La source en question a été modifiée afin d'intégrer les remontées
> spécifiées :
> - http://sqlfr.com/code.aspx?ID6635
>
> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
> me provoque des erreurs comme par exemple :
>
> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
> qui remontent :
> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
> Impossible de trouver un index nommé 'restorefile' dans la table
> 'restorefile'.
> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
> contactez l'administrateur du système.
>
> ou encore :
> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
> qui remontent :
> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
> Impossible de trouver un index nommé 'restorefilegroup' dans la table
> 'restorefilegroup'.
> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
> contactez l'administrateur du système.
>
>
> J'en ai plusieurs comme ca uniquement sur ces deux bases.
> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
> suis preneur ?
>
--
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.datasapiens.com ***********************
Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
"SQLpro [MVP]" a écrit :dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
"SQLpro [MVP]" a écrit :
dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :
Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
"SQLpro [MVP]" a écrit :dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
Racimo a écrit :
> Il est totalement inutile de se concentrer sur l'aspect
> indexation/defragmentation car il me semble clair que celà ne constitue pas
> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
> de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +
>
> "SQLpro [MVP]" a écrit :
>
>> dans la table sysindexes toute table, même sans index est répertoriée.
>>
>> il ne faut pas prendre en compte ces tables là.
>>
>> A +
>>
>> Romelard Fabrice [MVP] a écrit :
>>> Bonsoir,
>>>
>>> La source en question a été modifiée afin d'intégrer les remontées
>>> spécifiées :
>>> - http://sqlfr.com/code.aspx?ID6635
>>>
>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>> me provoque des erreurs comme par exemple :
>>>
>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>> qui remontent :
>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>> 'restorefile'.
>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>> contactez l'administrateur du système.
>>>
>>> ou encore :
>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>> qui remontent :
>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>> 'restorefilegroup'.
>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>> contactez l'administrateur du système.
>>>
>>>
>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>> suis preneur ?
>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
Racimo a écrit :
> Il est totalement inutile de se concentrer sur l'aspect
> indexation/defragmentation car il me semble clair que celà ne constitue pas
> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
> de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +
>
> "SQLpro [MVP]" a écrit :
>
>> dans la table sysindexes toute table, même sans index est répertoriée.
>>
>> il ne faut pas prendre en compte ces tables là.
>>
>> A +
>>
>> Romelard Fabrice [MVP] a écrit :
>>> Bonsoir,
>>>
>>> La source en question a été modifiée afin d'intégrer les remontées
>>> spécifiées :
>>> - http://sqlfr.com/code.aspx?ID6635
>>>
>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>> me provoque des erreurs comme par exemple :
>>>
>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>> qui remontent :
>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>> 'restorefile'.
>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>> contactez l'administrateur du système.
>>>
>>> ou encore :
>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>> qui remontent :
>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>> 'restorefilegroup'.
>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>> contactez l'administrateur du système.
>>>
>>>
>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>> suis preneur ?
>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
Racimo a écrit :
> Il est totalement inutile de se concentrer sur l'aspect
> indexation/defragmentation car il me semble clair que celà ne constitue pas
> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
> de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +
>
> "SQLpro [MVP]" a écrit :
>
>> dans la table sysindexes toute table, même sans index est répertoriée.
>>
>> il ne faut pas prendre en compte ces tables là.
>>
>> A +
>>
>> Romelard Fabrice [MVP] a écrit :
>>> Bonsoir,
>>>
>>> La source en question a été modifiée afin d'intégrer les remontées
>>> spécifiées :
>>> - http://sqlfr.com/code.aspx?ID6635
>>>
>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>> me provoque des erreurs comme par exemple :
>>>
>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>> qui remontent :
>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>> 'restorefile'.
>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>> contactez l'administrateur du système.
>>>
>>> ou encore :
>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>> qui remontent :
>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>> 'restorefilegroup'.
>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>> contactez l'administrateur du système.
>>>
>>>
>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>> suis preneur ?
>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
<<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
menu de left click "ATTENTION ne fonctionne pas très bien".
"SQLpro [MVP]" a écrit :Racimo a écrit :Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +"SQLpro [MVP]" a écrit :dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
<<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
menu de left click "ATTENTION ne fonctionne pas très bien".
"SQLpro [MVP]" a écrit :
Racimo a écrit :
Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +
"SQLpro [MVP]" a écrit :
dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :
Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
<<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
menu de left click "ATTENTION ne fonctionne pas très bien".
"SQLpro [MVP]" a écrit :Racimo a écrit :Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +"SQLpro [MVP]" a écrit :dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
Racimo a écrit :
> <<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
> C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
> fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
> que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
> menu de left click "ATTENTION ne fonctionne pas très bien".
je ne dirait pas cela !
SQL server offre une grande richesse d'outils qui sont plus ou moins
bien adapté a diverses situation.
Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
Le frein à main fonctionne nettement moins bien que la pédale de frein
sur une voiture. Si les gens s'en servent à la place de la pédale de
frein et constatent que cela freine beaucoup moins bien est-ce la
voiture qui est en cause ou le conducteur ???
A +
>
>
> "SQLpro [MVP]" a écrit :
>
>> Racimo a écrit :
>>> Il est totalement inutile de se concentrer sur l'aspect
>>> indexation/defragmentation car il me semble clair que celà ne constitue pas
>>> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
>>> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
>>> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
>>> de curseurs, notamment du côté des applications frontales.
>> mon pauvre!!!! tu prêche un convertit ;-)
>>
>> C'est ce que je prône depuis maintenant une décennie...
>>
>> Et dans mes audits je continue a voir des curseurs en pagaille partout !
>>
>> voici pourtant les papiers que j'ai écrit à ce sujet :
>> 1) optimisation et curseurs :
>> http://sqlpro.developpez.com/cours/optimiser/#L10
>> paragrahe 10. dernières lignes...
>> 2) éradiquer les curseurs dans MS SQL Server :
>> http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
>>
>> et dans les formations d'optimisation que je distille même combat !
>>
>> A +
>>
>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> dans la table sysindexes toute table, même sans index est répertoriée.
>>>>
>>>> il ne faut pas prendre en compte ces tables là.
>>>>
>>>> A +
>>>>
>>>> Romelard Fabrice [MVP] a écrit :
>>>>> Bonsoir,
>>>>>
>>>>> La source en question a été modifiée afin d'intégrer les remontées
>>>>> spécifiées :
>>>>> - http://sqlfr.com/code.aspx?ID6635
>>>>>
>>>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>>>> me provoque des erreurs comme par exemple :
>>>>>
>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>>>> qui remontent :
>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>>>> 'restorefile'.
>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>> contactez l'administrateur du système.
>>>>>
>>>>> ou encore :
>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>>>> qui remontent :
>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>>>> 'restorefilegroup'.
>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>> contactez l'administrateur du système.
>>>>>
>>>>>
>>>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>>>> suis preneur ?
>>>>>
>>>> --
>>>> 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.datasapiens.com ***********************
>>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
Racimo a écrit :
> <<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
> C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
> fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
> que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
> menu de left click "ATTENTION ne fonctionne pas très bien".
je ne dirait pas cela !
SQL server offre une grande richesse d'outils qui sont plus ou moins
bien adapté a diverses situation.
Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
Le frein à main fonctionne nettement moins bien que la pédale de frein
sur une voiture. Si les gens s'en servent à la place de la pédale de
frein et constatent que cela freine beaucoup moins bien est-ce la
voiture qui est en cause ou le conducteur ???
A +
>
>
> "SQLpro [MVP]" a écrit :
>
>> Racimo a écrit :
>>> Il est totalement inutile de se concentrer sur l'aspect
>>> indexation/defragmentation car il me semble clair que celà ne constitue pas
>>> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
>>> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
>>> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
>>> de curseurs, notamment du côté des applications frontales.
>> mon pauvre!!!! tu prêche un convertit ;-)
>>
>> C'est ce que je prône depuis maintenant une décennie...
>>
>> Et dans mes audits je continue a voir des curseurs en pagaille partout !
>>
>> voici pourtant les papiers que j'ai écrit à ce sujet :
>> 1) optimisation et curseurs :
>> http://sqlpro.developpez.com/cours/optimiser/#L10
>> paragrahe 10. dernières lignes...
>> 2) éradiquer les curseurs dans MS SQL Server :
>> http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
>>
>> et dans les formations d'optimisation que je distille même combat !
>>
>> A +
>>
>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> dans la table sysindexes toute table, même sans index est répertoriée.
>>>>
>>>> il ne faut pas prendre en compte ces tables là.
>>>>
>>>> A +
>>>>
>>>> Romelard Fabrice [MVP] a écrit :
>>>>> Bonsoir,
>>>>>
>>>>> La source en question a été modifiée afin d'intégrer les remontées
>>>>> spécifiées :
>>>>> - http://sqlfr.com/code.aspx?ID6635
>>>>>
>>>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>>>> me provoque des erreurs comme par exemple :
>>>>>
>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>>>> qui remontent :
>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>>>> 'restorefile'.
>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>> contactez l'administrateur du système.
>>>>>
>>>>> ou encore :
>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>>>> qui remontent :
>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>>>> 'restorefilegroup'.
>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>> contactez l'administrateur du système.
>>>>>
>>>>>
>>>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>>>> suis preneur ?
>>>>>
>>>> --
>>>> 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.datasapiens.com ***********************
>>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
Racimo a écrit :
> <<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
> C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
> fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
> que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
> menu de left click "ATTENTION ne fonctionne pas très bien".
je ne dirait pas cela !
SQL server offre une grande richesse d'outils qui sont plus ou moins
bien adapté a diverses situation.
Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
Le frein à main fonctionne nettement moins bien que la pédale de frein
sur une voiture. Si les gens s'en servent à la place de la pédale de
frein et constatent que cela freine beaucoup moins bien est-ce la
voiture qui est en cause ou le conducteur ???
A +
>
>
> "SQLpro [MVP]" a écrit :
>
>> Racimo a écrit :
>>> Il est totalement inutile de se concentrer sur l'aspect
>>> indexation/defragmentation car il me semble clair que celà ne constitue pas
>>> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
>>> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
>>> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
>>> de curseurs, notamment du côté des applications frontales.
>> mon pauvre!!!! tu prêche un convertit ;-)
>>
>> C'est ce que je prône depuis maintenant une décennie...
>>
>> Et dans mes audits je continue a voir des curseurs en pagaille partout !
>>
>> voici pourtant les papiers que j'ai écrit à ce sujet :
>> 1) optimisation et curseurs :
>> http://sqlpro.developpez.com/cours/optimiser/#L10
>> paragrahe 10. dernières lignes...
>> 2) éradiquer les curseurs dans MS SQL Server :
>> http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
>>
>> et dans les formations d'optimisation que je distille même combat !
>>
>> A +
>>
>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> dans la table sysindexes toute table, même sans index est répertoriée.
>>>>
>>>> il ne faut pas prendre en compte ces tables là.
>>>>
>>>> A +
>>>>
>>>> Romelard Fabrice [MVP] a écrit :
>>>>> Bonsoir,
>>>>>
>>>>> La source en question a été modifiée afin d'intégrer les remontées
>>>>> spécifiées :
>>>>> - http://sqlfr.com/code.aspx?ID6635
>>>>>
>>>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>>>> me provoque des erreurs comme par exemple :
>>>>>
>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>>>> qui remontent :
>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>>>> 'restorefile'.
>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>> contactez l'administrateur du système.
>>>>>
>>>>> ou encore :
>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>>>> qui remontent :
>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>>>> 'restorefilegroup'.
>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>> contactez l'administrateur du système.
>>>>>
>>>>>
>>>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>>>> suis preneur ?
>>>>>
>>>> --
>>>> 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.datasapiens.com ***********************
>>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
<<Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.>>
Ce qui n'a aucun sens, c'est d'essayer de se convaincre qu'une
fonctionnalité universellement connue comme défaillante auprès des
utilisateurs l'ayant effectivement implémentée sur des bases de taille
respectable du produit et ce QUELQUE SOIT le niveau d'optimisation
Je le répète les fonctionnalités de BLOB, XML ne fonctionnent PAS un point
c'est tout car leur utilisation crée beaucoup plus d'ennuis qu'elle n'en
resoud et par ailleurs, la durée de vie d'une tel système dépasse rarement 1
an ou 100Go...En un mot, c'est une fonctionnalité mignonne pour un
developpeur localement pour se faire plaisir mais déployer cette solution au
niveau industriel , c'est franchement de la rigolade ....
Pour info, en tout et pour tout 6 developpeurs ont VRAIMENT testé ces
fonctionnalités chez MS avec des stress tools et leur conclusions sont
unanimes ca ne tiens pas (A moins bien sur de multiplier par un ratio de fou
la puissance matérielle)...(je tiens çelà d'une personnes ayant participé au
projet Yukon)
Pour reprendre l'analogie de la voiture pour moi un moteur de voiture qui
explose à 120 KM (même s'il fonctionne parfaitement en deçà) est un moteur
qui ne fonctionne pas. Un point c'est tout...Celà ne veut pas dire que TOUT
SQL Server (qui est dans l'ensemble un bon produit) n'est pas bon mais que
ces fonctionnalités précises sont défaillantes (elles font actuellement
l'objet d'une refonte serieuse pour KATMAI)...Désolé ca fait longtemps que je
ne crois plus au blabla marketing (qu'il vienne de MS, ORACLE, ou IBM)...;)
Peut être devrions nous entendre pour ne pas être d'accords ;)
"SQLpro [MVP]" a écrit :Racimo a écrit :<<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
menu de left click "ATTENTION ne fonctionne pas très bien".
je ne dirait pas cela !
SQL server offre une grande richesse d'outils qui sont plus ou moins
bien adapté a diverses situation.
Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
Le frein à main fonctionne nettement moins bien que la pédale de frein
sur une voiture. Si les gens s'en servent à la place de la pédale de
frein et constatent que cela freine beaucoup moins bien est-ce la
voiture qui est en cause ou le conducteur ???
A +
"SQLpro [MVP]" a écrit :Racimo a écrit :Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +"SQLpro [MVP]" a écrit :dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
<<Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.>>
Ce qui n'a aucun sens, c'est d'essayer de se convaincre qu'une
fonctionnalité universellement connue comme défaillante auprès des
utilisateurs l'ayant effectivement implémentée sur des bases de taille
respectable du produit et ce QUELQUE SOIT le niveau d'optimisation
Je le répète les fonctionnalités de BLOB, XML ne fonctionnent PAS un point
c'est tout car leur utilisation crée beaucoup plus d'ennuis qu'elle n'en
resoud et par ailleurs, la durée de vie d'une tel système dépasse rarement 1
an ou 100Go...En un mot, c'est une fonctionnalité mignonne pour un
developpeur localement pour se faire plaisir mais déployer cette solution au
niveau industriel , c'est franchement de la rigolade ....
Pour info, en tout et pour tout 6 developpeurs ont VRAIMENT testé ces
fonctionnalités chez MS avec des stress tools et leur conclusions sont
unanimes ca ne tiens pas (A moins bien sur de multiplier par un ratio de fou
la puissance matérielle)...(je tiens çelà d'une personnes ayant participé au
projet Yukon)
Pour reprendre l'analogie de la voiture pour moi un moteur de voiture qui
explose à 120 KM (même s'il fonctionne parfaitement en deçà) est un moteur
qui ne fonctionne pas. Un point c'est tout...Celà ne veut pas dire que TOUT
SQL Server (qui est dans l'ensemble un bon produit) n'est pas bon mais que
ces fonctionnalités précises sont défaillantes (elles font actuellement
l'objet d'une refonte serieuse pour KATMAI)...Désolé ca fait longtemps que je
ne crois plus au blabla marketing (qu'il vienne de MS, ORACLE, ou IBM)...;)
Peut être devrions nous entendre pour ne pas être d'accords ;)
"SQLpro [MVP]" a écrit :
Racimo a écrit :
<<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
menu de left click "ATTENTION ne fonctionne pas très bien".
je ne dirait pas cela !
SQL server offre une grande richesse d'outils qui sont plus ou moins
bien adapté a diverses situation.
Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
Le frein à main fonctionne nettement moins bien que la pédale de frein
sur une voiture. Si les gens s'en servent à la place de la pédale de
frein et constatent que cela freine beaucoup moins bien est-ce la
voiture qui est en cause ou le conducteur ???
A +
"SQLpro [MVP]" a écrit :
Racimo a écrit :
Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +
"SQLpro [MVP]" a écrit :
dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :
Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
<<Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.>>
Ce qui n'a aucun sens, c'est d'essayer de se convaincre qu'une
fonctionnalité universellement connue comme défaillante auprès des
utilisateurs l'ayant effectivement implémentée sur des bases de taille
respectable du produit et ce QUELQUE SOIT le niveau d'optimisation
Je le répète les fonctionnalités de BLOB, XML ne fonctionnent PAS un point
c'est tout car leur utilisation crée beaucoup plus d'ennuis qu'elle n'en
resoud et par ailleurs, la durée de vie d'une tel système dépasse rarement 1
an ou 100Go...En un mot, c'est une fonctionnalité mignonne pour un
developpeur localement pour se faire plaisir mais déployer cette solution au
niveau industriel , c'est franchement de la rigolade ....
Pour info, en tout et pour tout 6 developpeurs ont VRAIMENT testé ces
fonctionnalités chez MS avec des stress tools et leur conclusions sont
unanimes ca ne tiens pas (A moins bien sur de multiplier par un ratio de fou
la puissance matérielle)...(je tiens çelà d'une personnes ayant participé au
projet Yukon)
Pour reprendre l'analogie de la voiture pour moi un moteur de voiture qui
explose à 120 KM (même s'il fonctionne parfaitement en deçà) est un moteur
qui ne fonctionne pas. Un point c'est tout...Celà ne veut pas dire que TOUT
SQL Server (qui est dans l'ensemble un bon produit) n'est pas bon mais que
ces fonctionnalités précises sont défaillantes (elles font actuellement
l'objet d'une refonte serieuse pour KATMAI)...Désolé ca fait longtemps que je
ne crois plus au blabla marketing (qu'il vienne de MS, ORACLE, ou IBM)...;)
Peut être devrions nous entendre pour ne pas être d'accords ;)
"SQLpro [MVP]" a écrit :Racimo a écrit :<<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
menu de left click "ATTENTION ne fonctionne pas très bien".
je ne dirait pas cela !
SQL server offre une grande richesse d'outils qui sont plus ou moins
bien adapté a diverses situation.
Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
Le frein à main fonctionne nettement moins bien que la pédale de frein
sur une voiture. Si les gens s'en servent à la place de la pédale de
frein et constatent que cela freine beaucoup moins bien est-ce la
voiture qui est en cause ou le conducteur ???
A +
"SQLpro [MVP]" a écrit :Racimo a écrit :Il est totalement inutile de se concentrer sur l'aspect
indexation/defragmentation car il me semble clair que celà ne constitue pas
le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
de curseurs, notamment du côté des applications frontales.
mon pauvre!!!! tu prêche un convertit ;-)
C'est ce que je prône depuis maintenant une décennie...
Et dans mes audits je continue a voir des curseurs en pagaille partout !
voici pourtant les papiers que j'ai écrit à ce sujet :
1) optimisation et curseurs :
http://sqlpro.developpez.com/cours/optimiser/#L10
paragrahe 10. dernières lignes...
2) éradiquer les curseurs dans MS SQL Server :
http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
et dans les formations d'optimisation que je distille même combat !
A +"SQLpro [MVP]" a écrit :dans la table sysindexes toute table, même sans index est répertoriée.
il ne faut pas prendre en compte ces tables là.
A +
Romelard Fabrice [MVP] a écrit :Bonsoir,
La source en question a été modifiée afin d'intégrer les remontées
spécifiées :
- http://sqlfr.com/code.aspx?ID6635
J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
me provoque des erreurs comme par exemple :
DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
Impossible de trouver un index nommé 'restorefile' dans la table
'restorefile'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
ou encore :
DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
qui remontent :
Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
Impossible de trouver un index nommé 'restorefilegroup' dans la table
'restorefilegroup'.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur du système.
J'en ai plusieurs comme ca uniquement sur ces deux bases.
Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
suis preneur ?
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
--
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.datasapiens.com ***********************
Racimo a écrit :
> <<Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.>>
> Ce qui n'a aucun sens, c'est d'essayer de se convaincre qu'une
> fonctionnalité universellement connue comme défaillante auprès des
> utilisateurs l'ayant effectivement implémentée sur des bases de taille
> respectable du produit et ce QUELQUE SOIT le niveau d'optimisation
>
> Je le répète les fonctionnalités de BLOB, XML ne fonctionnent PAS un point
> c'est tout car leur utilisation crée beaucoup plus d'ennuis qu'elle n'en
> resoud et par ailleurs, la durée de vie d'une tel système dépasse rarement 1
> an ou 100Go...En un mot, c'est une fonctionnalité mignonne pour un
> developpeur localement pour se faire plaisir mais déployer cette solution au
> niveau industriel , c'est franchement de la rigolade ....
je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.
En particulier le type XML de SQL Server 2005 est assez performant
lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
Oracle par exemple.
SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
validé et contre validabe, indexable et requêtable (à l'aide de XPath et
XQuery et l'opérateur APPLY au sein d'une requête SQL).
Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
être utilisé parcimonieusement et base de données XML comme Tamino d'AG
Software.
La vocation de MS SQL Server est de se servir accesoirement de xml, pas
de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
l'air d'oublier !
>
> Pour info, en tout et pour tout 6 developpeurs ont VRAIMENT testé ces
> fonctionnalités chez MS avec des stress tools et leur conclusions sont
> unanimes ca ne tiens pas (A moins bien sur de multiplier par un ratio de fou
> la puissance matérielle)...(je tiens çelà d'une personnes ayant participé au
> projet Yukon)
Donnez des noms, des faits, des mesures et des papiers sur le sujet !
>
> Pour reprendre l'analogie de la voiture pour moi un moteur de voiture qui
> explose à 120 KM (même s'il fonctionne parfaitement en deçà) est un moteur
> qui ne fonctionne pas. Un point c'est tout...Celà ne veut pas dire que TOUT
> SQL Server (qui est dans l'ensemble un bon produit) n'est pas bon mais que
> ces fonctionnalités précises sont défaillantes (elles font actuellement
> l'objet d'une refonte serieuse pour KATMAI)...Désolé ca fait longtemps que je
> ne crois plus au blabla marketing (qu'il vienne de MS, ORACLE, ou IBM)...;)
moi non plus, je ne suis pas formaté au discours MS. Mes humeurs sur le
sujet sont légion !
A +
>
> Peut être devrions nous entendre pour ne pas être d'accords ;)
>
>
> "SQLpro [MVP]" a écrit :
>
>> Racimo a écrit :
>>> <<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
>>> C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
>>> fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
>>> que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
>>> menu de left click "ATTENTION ne fonctionne pas très bien".
>> je ne dirait pas cela !
>>
>> SQL server offre une grande richesse d'outils qui sont plus ou moins
>> bien adapté a diverses situation.
>>
>> Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
>>
>> Le frein à main fonctionne nettement moins bien que la pédale de frein
>> sur une voiture. Si les gens s'en servent à la place de la pédale de
>> frein et constatent que cela freine beaucoup moins bien est-ce la
>> voiture qui est en cause ou le conducteur ???
>>
>> A +
>>
>>
>>
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> Racimo a écrit :
>>>>> Il est totalement inutile de se concentrer sur l'aspect
>>>>> indexation/defragmentation car il me semble clair que celà ne constitue pas
>>>>> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
>>>>> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
>>>>> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
>>>>> de curseurs, notamment du côté des applications frontales.
>>>> mon pauvre!!!! tu prêche un convertit ;-)
>>>>
>>>> C'est ce que je prône depuis maintenant une décennie...
>>>>
>>>> Et dans mes audits je continue a voir des curseurs en pagaille partout !
>>>>
>>>> voici pourtant les papiers que j'ai écrit à ce sujet :
>>>> 1) optimisation et curseurs :
>>>> http://sqlpro.developpez.com/cours/optimiser/#L10
>>>> paragrahe 10. dernières lignes...
>>>> 2) éradiquer les curseurs dans MS SQL Server :
>>>> http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
>>>>
>>>> et dans les formations d'optimisation que je distille même combat !
>>>>
>>>> A +
>>>>
>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> dans la table sysindexes toute table, même sans index est répertoriée.
>>>>>>
>>>>>> il ne faut pas prendre en compte ces tables là.
>>>>>>
>>>>>> A +
>>>>>>
>>>>>> Romelard Fabrice [MVP] a écrit :
>>>>>>> Bonsoir,
>>>>>>>
>>>>>>> La source en question a été modifiée afin d'intégrer les remontées
>>>>>>> spécifiées :
>>>>>>> - http://sqlfr.com/code.aspx?ID6635
>>>>>>>
>>>>>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>>>>>> me provoque des erreurs comme par exemple :
>>>>>>>
>>>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>>>>>> qui remontent :
>>>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>>>>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>>>>>> 'restorefile'.
>>>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>>>> contactez l'administrateur du système.
>>>>>>>
>>>>>>> ou encore :
>>>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>>>>>> qui remontent :
>>>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>>>>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>>>>>> 'restorefilegroup'.
>>>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>>>> contactez l'administrateur du système.
>>>>>>>
>>>>>>>
>>>>>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>>>>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>>>>>> suis preneur ?
>>>>>>>
>>>>>> --
>>>>>> 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.datasapiens.com ***********************
>>>>>>
>>>> --
>>>> 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.datasapiens.com ***********************
>>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
Racimo a écrit :
> <<Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.>>
> Ce qui n'a aucun sens, c'est d'essayer de se convaincre qu'une
> fonctionnalité universellement connue comme défaillante auprès des
> utilisateurs l'ayant effectivement implémentée sur des bases de taille
> respectable du produit et ce QUELQUE SOIT le niveau d'optimisation
>
> Je le répète les fonctionnalités de BLOB, XML ne fonctionnent PAS un point
> c'est tout car leur utilisation crée beaucoup plus d'ennuis qu'elle n'en
> resoud et par ailleurs, la durée de vie d'une tel système dépasse rarement 1
> an ou 100Go...En un mot, c'est une fonctionnalité mignonne pour un
> developpeur localement pour se faire plaisir mais déployer cette solution au
> niveau industriel , c'est franchement de la rigolade ....
je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.
En particulier le type XML de SQL Server 2005 est assez performant
lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
Oracle par exemple.
SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
validé et contre validabe, indexable et requêtable (à l'aide de XPath et
XQuery et l'opérateur APPLY au sein d'une requête SQL).
Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
être utilisé parcimonieusement et base de données XML comme Tamino d'AG
Software.
La vocation de MS SQL Server est de se servir accesoirement de xml, pas
de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
l'air d'oublier !
>
> Pour info, en tout et pour tout 6 developpeurs ont VRAIMENT testé ces
> fonctionnalités chez MS avec des stress tools et leur conclusions sont
> unanimes ca ne tiens pas (A moins bien sur de multiplier par un ratio de fou
> la puissance matérielle)...(je tiens çelà d'une personnes ayant participé au
> projet Yukon)
Donnez des noms, des faits, des mesures et des papiers sur le sujet !
>
> Pour reprendre l'analogie de la voiture pour moi un moteur de voiture qui
> explose à 120 KM (même s'il fonctionne parfaitement en deçà) est un moteur
> qui ne fonctionne pas. Un point c'est tout...Celà ne veut pas dire que TOUT
> SQL Server (qui est dans l'ensemble un bon produit) n'est pas bon mais que
> ces fonctionnalités précises sont défaillantes (elles font actuellement
> l'objet d'une refonte serieuse pour KATMAI)...Désolé ca fait longtemps que je
> ne crois plus au blabla marketing (qu'il vienne de MS, ORACLE, ou IBM)...;)
moi non plus, je ne suis pas formaté au discours MS. Mes humeurs sur le
sujet sont légion !
A +
>
> Peut être devrions nous entendre pour ne pas être d'accords ;)
>
>
> "SQLpro [MVP]" a écrit :
>
>> Racimo a écrit :
>>> <<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
>>> C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
>>> fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
>>> que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
>>> menu de left click "ATTENTION ne fonctionne pas très bien".
>> je ne dirait pas cela !
>>
>> SQL server offre une grande richesse d'outils qui sont plus ou moins
>> bien adapté a diverses situation.
>>
>> Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
>>
>> Le frein à main fonctionne nettement moins bien que la pédale de frein
>> sur une voiture. Si les gens s'en servent à la place de la pédale de
>> frein et constatent que cela freine beaucoup moins bien est-ce la
>> voiture qui est en cause ou le conducteur ???
>>
>> A +
>>
>>
>>
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> Racimo a écrit :
>>>>> Il est totalement inutile de se concentrer sur l'aspect
>>>>> indexation/defragmentation car il me semble clair que celà ne constitue pas
>>>>> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
>>>>> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
>>>>> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
>>>>> de curseurs, notamment du côté des applications frontales.
>>>> mon pauvre!!!! tu prêche un convertit ;-)
>>>>
>>>> C'est ce que je prône depuis maintenant une décennie...
>>>>
>>>> Et dans mes audits je continue a voir des curseurs en pagaille partout !
>>>>
>>>> voici pourtant les papiers que j'ai écrit à ce sujet :
>>>> 1) optimisation et curseurs :
>>>> http://sqlpro.developpez.com/cours/optimiser/#L10
>>>> paragrahe 10. dernières lignes...
>>>> 2) éradiquer les curseurs dans MS SQL Server :
>>>> http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
>>>>
>>>> et dans les formations d'optimisation que je distille même combat !
>>>>
>>>> A +
>>>>
>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> dans la table sysindexes toute table, même sans index est répertoriée.
>>>>>>
>>>>>> il ne faut pas prendre en compte ces tables là.
>>>>>>
>>>>>> A +
>>>>>>
>>>>>> Romelard Fabrice [MVP] a écrit :
>>>>>>> Bonsoir,
>>>>>>>
>>>>>>> La source en question a été modifiée afin d'intégrer les remontées
>>>>>>> spécifiées :
>>>>>>> - http://sqlfr.com/code.aspx?ID6635
>>>>>>>
>>>>>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>>>>>> me provoque des erreurs comme par exemple :
>>>>>>>
>>>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>>>>>> qui remontent :
>>>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>>>>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>>>>>> 'restorefile'.
>>>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>>>> contactez l'administrateur du système.
>>>>>>>
>>>>>>> ou encore :
>>>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>>>>>> qui remontent :
>>>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>>>>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>>>>>> 'restorefilegroup'.
>>>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>>>> contactez l'administrateur du système.
>>>>>>>
>>>>>>>
>>>>>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>>>>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>>>>>> suis preneur ?
>>>>>>>
>>>>>> --
>>>>>> 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.datasapiens.com ***********************
>>>>>>
>>>> --
>>>> 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.datasapiens.com ***********************
>>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
Racimo a écrit :
> <<Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.>>
> Ce qui n'a aucun sens, c'est d'essayer de se convaincre qu'une
> fonctionnalité universellement connue comme défaillante auprès des
> utilisateurs l'ayant effectivement implémentée sur des bases de taille
> respectable du produit et ce QUELQUE SOIT le niveau d'optimisation
>
> Je le répète les fonctionnalités de BLOB, XML ne fonctionnent PAS un point
> c'est tout car leur utilisation crée beaucoup plus d'ennuis qu'elle n'en
> resoud et par ailleurs, la durée de vie d'une tel système dépasse rarement 1
> an ou 100Go...En un mot, c'est une fonctionnalité mignonne pour un
> developpeur localement pour se faire plaisir mais déployer cette solution au
> niveau industriel , c'est franchement de la rigolade ....
je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.
En particulier le type XML de SQL Server 2005 est assez performant
lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
Oracle par exemple.
SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
validé et contre validabe, indexable et requêtable (à l'aide de XPath et
XQuery et l'opérateur APPLY au sein d'une requête SQL).
Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
être utilisé parcimonieusement et base de données XML comme Tamino d'AG
Software.
La vocation de MS SQL Server est de se servir accesoirement de xml, pas
de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
l'air d'oublier !
>
> Pour info, en tout et pour tout 6 developpeurs ont VRAIMENT testé ces
> fonctionnalités chez MS avec des stress tools et leur conclusions sont
> unanimes ca ne tiens pas (A moins bien sur de multiplier par un ratio de fou
> la puissance matérielle)...(je tiens çelà d'une personnes ayant participé au
> projet Yukon)
Donnez des noms, des faits, des mesures et des papiers sur le sujet !
>
> Pour reprendre l'analogie de la voiture pour moi un moteur de voiture qui
> explose à 120 KM (même s'il fonctionne parfaitement en deçà) est un moteur
> qui ne fonctionne pas. Un point c'est tout...Celà ne veut pas dire que TOUT
> SQL Server (qui est dans l'ensemble un bon produit) n'est pas bon mais que
> ces fonctionnalités précises sont défaillantes (elles font actuellement
> l'objet d'une refonte serieuse pour KATMAI)...Désolé ca fait longtemps que je
> ne crois plus au blabla marketing (qu'il vienne de MS, ORACLE, ou IBM)...;)
moi non plus, je ne suis pas formaté au discours MS. Mes humeurs sur le
sujet sont légion !
A +
>
> Peut être devrions nous entendre pour ne pas être d'accords ;)
>
>
> "SQLpro [MVP]" a écrit :
>
>> Racimo a écrit :
>>> <<Et dans mes audits je continue a voir des curseurs en pagaille partout !>>
>>> C'est NORMAL...Tant que MS continue d'intégrer des fonctionnalités qui ne
>>> fonctionnent PAS ou MAL (entre autre XML et BLOB), il est totalement NORMAL
>>> que les gens tentent de les utiliser...ou alors MS devrait écrire dans les
>>> menu de left click "ATTENTION ne fonctionne pas très bien".
>> je ne dirait pas cela !
>>
>> SQL server offre une grande richesse d'outils qui sont plus ou moins
>> bien adapté a diverses situation.
>>
>> Dire que ceci ou cela ne fonctionne pas très bien n'a aucun sens.
>>
>> Le frein à main fonctionne nettement moins bien que la pédale de frein
>> sur une voiture. Si les gens s'en servent à la place de la pédale de
>> frein et constatent que cela freine beaucoup moins bien est-ce la
>> voiture qui est en cause ou le conducteur ???
>>
>> A +
>>
>>
>>
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> Racimo a écrit :
>>>>> Il est totalement inutile de se concentrer sur l'aspect
>>>>> indexation/defragmentation car il me semble clair que celà ne constitue pas
>>>>> le levier principal d'optimisation...Se débarasser des curseurs (qui dans 90%
>>>>> des cas PEUVENT et DOIVENT etre réecri sous la forme de SQL simple) sera
>>>>> probablement beaucoup plus probants. Une fois pour toute ne *PAS* utiliser
>>>>> de curseurs, notamment du côté des applications frontales.
>>>> mon pauvre!!!! tu prêche un convertit ;-)
>>>>
>>>> C'est ce que je prône depuis maintenant une décennie...
>>>>
>>>> Et dans mes audits je continue a voir des curseurs en pagaille partout !
>>>>
>>>> voici pourtant les papiers que j'ai écrit à ce sujet :
>>>> 1) optimisation et curseurs :
>>>> http://sqlpro.developpez.com/cours/optimiser/#L10
>>>> paragrahe 10. dernières lignes...
>>>> 2) éradiquer les curseurs dans MS SQL Server :
>>>> http://sqlpro.developpez.com/cours/sqlserver/MSSQLServer_avoidCursor/
>>>>
>>>> et dans les formations d'optimisation que je distille même combat !
>>>>
>>>> A +
>>>>
>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> dans la table sysindexes toute table, même sans index est répertoriée.
>>>>>>
>>>>>> il ne faut pas prendre en compte ces tables là.
>>>>>>
>>>>>> A +
>>>>>>
>>>>>> Romelard Fabrice [MVP] a écrit :
>>>>>>> Bonsoir,
>>>>>>>
>>>>>>> La source en question a été modifiée afin d'intégrer les remontées
>>>>>>> spécifiées :
>>>>>>> - http://sqlfr.com/code.aspx?ID6635
>>>>>>>
>>>>>>> J'ai aussi supprimé de la première sélection les bases Master et MSDB, elles
>>>>>>> me provoque des erreurs comme par exemple :
>>>>>>>
>>>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefile', 'restorefile')
>>>>>>> qui remontent :
>>>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 1
>>>>>>> Impossible de trouver un index nommé 'restorefile' dans la table
>>>>>>> 'restorefile'.
>>>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>>>> contactez l'administrateur du système.
>>>>>>>
>>>>>>> ou encore :
>>>>>>> DBCC INDEXDEFRAG ('msdb', 'restorefilegroup', 'restorefilegroup')
>>>>>>> qui remontent :
>>>>>>> Serveur : Msg 7999, Niveau 16, État 8, Ligne 2
>>>>>>> Impossible de trouver un index nommé 'restorefilegroup' dans la table
>>>>>>> 'restorefilegroup'.
>>>>>>> Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
>>>>>>> contactez l'administrateur du système.
>>>>>>>
>>>>>>>
>>>>>>> J'en ai plusieurs comme ca uniquement sur ces deux bases.
>>>>>>> Je n'ai pas pu comprendre la source de ces erreurs, si qqun a une idée, je
>>>>>>> suis preneur ?
>>>>>>>
>>>>>> --
>>>>>> 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.datasapiens.com ***********************
>>>>>>
>>>> --
>>>> 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.datasapiens.com ***********************
>>>>
>>
>> --
>> 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.datasapiens.com ***********************
>>
--
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.datasapiens.com ***********************
Ci dessous les réponses aux points soulevés...
<<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.>>
Si vous pensez que je raconte des anneries sans donner le moindre argument
pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
que je peux dire c'est que j'ai eu l'opportunité de tester ces
fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
sont pragmatiques (j'ai vite abandonné cette solution).
Pouvez-vous en dire
autant pour dire que je raconte des anneries et que vous avez raison? Quelle
la plus grosse base binaire que vous avez géré au jour le jour?
<<En particulier le type XML de SQL Server 2005 est assez performant
lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
Oracle par exemple.
SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
validé et contre validabe, indexable et requêtable (à l'aide de XPath et
XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
strictement RIEN au data management)...
Les débats stériles du type SQL est
mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
"APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
words)
<<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
être utilisé parcimonieusement et base de données XML comme Tamino d'AG
Software.>>
XML est une abbération un point c'est tout.
Et ce sous n'importe quel type
d'implémentation . Il constitue une regression au niveau de modèle
hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
une telle structure. C'est aussi la raison pour laquelle le modèle
relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
en dira plus...
http://www.joelonsoftware.com/articles/fog0000000319.html
<<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
l'air d'oublier !>>
Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
souvent pas en mesure de voir ce genre de nuance....
<<Donnez des noms, des faits, des mesures et des papiers sur le sujet
!>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
partie de leur argumentaire commercial? Cette information, je la tiens d'un
collègue travaillant actuellement à Edmonton et qui a participé directement
au developpement du produit. Je ne révèlerai pas son nom pour des raisons
évidentes: cette personne travaille encore chez MS.
Ci dessous les réponses aux points soulevés...
<<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.>>
Si vous pensez que je raconte des anneries sans donner le moindre argument
pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
que je peux dire c'est que j'ai eu l'opportunité de tester ces
fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
sont pragmatiques (j'ai vite abandonné cette solution).
Pouvez-vous en dire
autant pour dire que je raconte des anneries et que vous avez raison? Quelle
la plus grosse base binaire que vous avez géré au jour le jour?
<<En particulier le type XML de SQL Server 2005 est assez performant
lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
Oracle par exemple.
SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
validé et contre validabe, indexable et requêtable (à l'aide de XPath et
XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
strictement RIEN au data management)...
Les débats stériles du type SQL est
mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
"APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
words)
<<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
être utilisé parcimonieusement et base de données XML comme Tamino d'AG
Software.>>
XML est une abbération un point c'est tout.
Et ce sous n'importe quel type
d'implémentation . Il constitue une regression au niveau de modèle
hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
une telle structure. C'est aussi la raison pour laquelle le modèle
relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
en dira plus...
http://www.joelonsoftware.com/articles/fog0000000319.html
<<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
l'air d'oublier !>>
Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
souvent pas en mesure de voir ce genre de nuance....
<<Donnez des noms, des faits, des mesures et des papiers sur le sujet
!>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
partie de leur argumentaire commercial? Cette information, je la tiens d'un
collègue travaillant actuellement à Edmonton et qui a participé directement
au developpement du produit. Je ne révèlerai pas son nom pour des raisons
évidentes: cette personne travaille encore chez MS.
Ci dessous les réponses aux points soulevés...
<<je pense que vous n'avez aucune expérience sur ce genre de sujet pour
dire de telles anneries.>>
Si vous pensez que je raconte des anneries sans donner le moindre argument
pour pouvoir le justifier alors le débat ne risque pas d'aller très loin...Ce
que je peux dire c'est que j'ai eu l'opportunité de tester ces
fonctionnalités à dimension industrielle (Gestion de Photothèque de plusieurs
millions d'images stockées sur SQL) et que les conclusions que j'en ai tiré
sont pragmatiques (j'ai vite abandonné cette solution).
Pouvez-vous en dire
autant pour dire que je raconte des anneries et que vous avez raison? Quelle
la plus grosse base binaire que vous avez géré au jour le jour?
<<En particulier le type XML de SQL Server 2005 est assez performant
lorsqu'il est proprement utilisé en comparaison de ce qui se fait sous
Oracle par exemple.
SQL Server 2005 est un des rares SGBDR a avoir un véritable type XML
validé et contre validabe, indexable et requêtable (à l'aide de XPath et
XQuery et l'opérateur APPLY au sein d'une requête SQL).>>
Sans vouloir paraitre insultant cette phrase ressemble beaucoup trop à de
l'argumentaire commercial MS. XML est une abbération en soit pour la gestion
de données (normal celui-ci a été crée par des éditeurs qui ne connaissent
strictement RIEN au data management)...
Les débats stériles du type SQL est
mieux que ORACLE sont une perte de temps pour l'évaluation objective de la
qualité d'une technologie. Les mots magiques du "XQuery" et des opérateurs
"APPLY" sont des accroches utilisées pour vanter les mérites d'un produit.
Je suis sûr que les amis d'ORACLE et DB2 ont des arguments équivalents (buzz
words)
<<Bien entendu il ne faut pas confondre SGBDR pour lequel le type XML doit
être utilisé parcimonieusement et base de données XML comme Tamino d'AG
Software.>>
XML est une abbération un point c'est tout.
Et ce sous n'importe quel type
d'implémentation . Il constitue une regression au niveau de modèle
hierarchique qui a démontré dans les années 60 une foule de problèmes liés à
sa structure et à l'inéfficacité avérée de l'algorythmie de recherche sous
une telle structure. C'est aussi la raison pour laquelle le modèle
relationnel a été crée. Si vous n'êtes pas convaincu, voici un lien qui vous
en dira plus...
http://www.joelonsoftware.com/articles/fog0000000319.html
<<La vocation de MS SQL Server est de se servir accesoirement de xml, pas
de se reposer unqiuement sur xml, ce que bon nombre de développeurs ont
l'air d'oublier !>>
Peut être, mais lorsque les developpeurs utilisent un produit il ne sont
souvent pas en mesure de voir ce genre de nuance....
<<Donnez des noms, des faits, des mesures et des papiers sur le sujet
!>>Etes vous naif au point de penser que l'on puisse obtenir ce genre
d'information OFFICIELLEMENT de MS. Pensez-vous vraiment que MS va publier
des résultats négatifs sur une fonctionnalité sur laquelle repose une grande
partie de leur argumentaire commercial? Cette information, je la tiens d'un
collègue travaillant actuellement à Edmonton et qui a participé directement
au developpement du produit. Je ne révèlerai pas son nom pour des raisons
évidentes: cette personne travaille encore chez MS.
