Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Parce que conseiller d'aller lire les logs pour trouver la date de démarrage de SQL Server c'était du temps de SQL Server 2000 !Envoyé par 7gyY9w1ZY6ySRgPeaefZ
Merci !
Mais pourquoi ?
Faut se recycler dans la vie !!!! Même le vieux crouton que je suis tente de lutter contre l'Alzheimer qui guette TOUT le monde !
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Ça me rappelle un type qui me sortait ses vieilles requêtes tirées de ses années d'école avec les jointures à l'ancienne façon oracle :
Mais si tu veux l'historique des derniers redémarrages, y a t-il une autre façon que de passer par les errorlogs ? Je ne cherche pas à m'obstiner, je veux juste savoir
Code : Sélectionner tout - Visualiser dans une fenêtre à part select * from emp, dept where emp.deptno = dept.deptno(+)
l'erreur log ne se constitue pas toujours par redémarrage puisque tu peut le faire cycler manuellement (sp_cycle_errorlog). Et dans d'autres circonstance (obscures...) il cycle tout seul !
A ma connaissance dans l'un des journaux d'événement de Windows....
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Ah oui ? J'ai jamais rencontré ça à date. De toute façon, j'augmente le nombre de fichiers conservé au cas où une personne fait une maintenance sur le serveur sans prévenir et redémarre plusieurs fois...
As-tu pu faire quelques EXPLAIN ?
Hum...ok, j'utilise "cardinalité" dans le contexte MCD: 0,n 1,1 1,n...
et plutôt "effectif" ou "population" ou tout simplement "nombre de lignes" dans ce cas
Dans la théorie relationnelle (cf. The New Relational Database Dictionary de C.J. Date) :
cardinality the number of tuples in the body of a relation
Dans la norme SQL, « cardinality » est un mot réservé.
Avec DB2 :
Par exemple avec l’instruction CREATE FUNCTION (cf. la doc officielle, SQL Reference) :
CARDINALITY integer
Specifies an estimate of the expected number of rows that the function returns.
Le mot figure dans le nom de la fonction MAX_CARDINALITY.
C’est le nom d’une colonne dans la table SYSIBM.SYSROUTINES.
Voir aussi la fonction BLOB
Etc.
Pour ma part j’ai utilisé le mot « cardinal », mais va savoir pourquoi, alors que Date utilise systématiquement le mot « cardinality »...
(a) Faites simple, mais pas plus simple ! (A. Einstein)
(b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
=> La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)
__________________________________
Bases de données relationnelles et normalisation : de la première à la sixième forme normale
Modéliser les données avec MySQL Workbench
Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.
Bonjour François
Non, pour l'instant je n'ai aucune requête sous la main, pas même la liste des traitements les plus longs, juste une durée globale du plan batch.
C'est cette durée qui m'a alerté, surtout en comparaison avec le nombre de mouvements à traiter, de l'ordre de quelques millions tout au plus, et qui requiert jusqu'à 3 jours de traitement en continu de façon récurrente (essentiellement les fins de mois)
My 2 cents:
Je travaille avec Aurea.CRM, une application qui, comme son nom l'indique, fait de la CRM.
Les tables sont des "InfoArea", et les triggers ne sont pas des bouts de code SQL, mais du paramétrage interprété par le serveur d'application, qu'on peut déclencher un peu quand on veut, y compris sur sélection.
Ainsi, quand tu lances une mise à jour de masse, genre "je recopie dans CA N-1 le contenu de la colonne CA N de tous mes clients au 1er janvier", tu spécifies une sélection sur FI (sociétés) avec le déclenchement d'un trigger qui effectue cette modification.
Bah, là où en SQL, tu fais "update FI set CAN1 = CAN, CAN = 0;" et ça met à jour quelques milliards de lignes en une fraction de seconde sur un serveur mal configuré, Aurea.CRM va :
1/ select * from FI lu dans un curseur
2/ Pour chaque ligne, exécuter un update FI set CAN1 = CAN, CAN = 0, RKZ = <un super varbinary de plusieurs Ko>, updl = sysdate upd_fields = <encore un super varbinary de plusieurs Ko> where id = ?
3/ 1 insert pout chaque ligne et chaque colonne : insert into h0 (...) values (un varbinary qui contient le nom de la table, le nom de l'ancienne colonne, l'ancienne valeur, la nouvelle, la date, l'utilisateur connecté).
4/ Commit à chaque ligne, sinon c'est pas drôle
Résultat, on a économisé quelques lignes de code de trigger (surtout pour construire les varbinary, qui sont évidemment du XML compressé puis chiffré), au profit de quelques cases à cocher dans un écran d'administration.
Et au lieu d'avoir une mise à jour bénigne qui dure au max 1 ou 2 secondes, trigger compris, qui rollback tout s'il y a une erreur ou si le traitement est interrompu, un magnifique popup qui fait défiler les lignes 1 à 1, sans se presser, qi va durer plusieurs heures sur un serveur surdimensionné et cerise sur le gâteau, en cas d'arrêt du traitement, ça laisse les données au milieu du gué, un vrai bonheur à rattraper ensuite !
Et pendant ce temps, en raison des commit incessants, des échanges entre le serveur d'application et de base de données, l'alternance entre travail sur le serveur de traitement (calcul des varbinary + compression + chiffrement) et les mises à jour sur le serveur (lecture, mise à jour, insertion, commit), on a les deux serveurs avec 1% à 2% de CPU utilisé, un réseau avec un grand max de 10 Ko/s utilisé, et pourtant un traitement interminable.
Tout ça pour dire que modélisation merdique = à 99% de chances traitements encore plus merdiques décorrélés de la base de donnée, et au final un bousin impossible à optimiser.
Résultat, avec cet outils, pour cette problématique, j'utilise maintenant des outils que je me suis fait qui font :
- sélection directe en SQL
- génération d'un CSV contenant les données à mettre à jour
- import du fichier
=> Ca évite (et permet de désactiver par exemple l'historisation dans la table H0, on s'en fout vu que c'est un traitement automatique) tout un tas de mécanismes internes qui plombent les performances. Le même résultat passe de plusieurs heures à quelques dizaines de secondes, ce qui reste élevé mais c'est mieux que rien.
Je te préconise du coup, après confirmation du niveau de pourrissitude du traitement, d'essayer de le contourner.
Courage !
On ne jouit bien que de ce qu’on partage.
Aurea c'est pas ceux qui ont racheté Generix? Un des pire produits avec lequel j'ai dû bossé. Je ne sais pas s'ils étaient fâchés avec Oracle quand ils ont créé le produit pour ce RDBMS, mais ils auraient pu concourir dans la catégorie des pires mauvaises pratiques à fuir. Je me dis ok, on a le droit de faire des erreurs et rectifier le tir, mais non, pas chez eux, le bousin est resté dans son jus de 20 ans, incroyable.
Oui c'est eux.
C'est eux aussi qui ont racheté Update.CRM, devenu Aurea.CRM
Le truc amusant, c'est que ma boîte distribuait du Generix, et quand ça a été racheté par Aurea on s'est dit "merde, faut qu'on se diversifie, si Aurea plante le produit (ce qu'ils ont fait aux 3/4), du coup on a distribué au Update.CRM... qui a été racheté dans la foulée par Aurea aussi
Le truc complètement improbable quand on sait que Generix = Oracle + Java et Update = SQL Server + .NET, genre la guerre des mondes
Bref, aussi bien dans Generix que dans Update, y'a pas que des trucs à jeter, autant c'est clair que niveau base de données, le jour où SQLpro tombe dessus, il fait une rupture d'anévrisme direct.
Le gros avantage de ces deux outils (enfin... Generix ça c'est bien viandé le jour où ils sont passé à la sauce Java/XML/XSL avec un niveau CAP boulangerie) c'est qu'on peut faire du spécifique, du paramétrage évolué etc. sans toucher une ligne de code.
C'est un avantage indéniable, notamment pour les consultants qui repassent derrière.
Maintenant on fait du Divalto / Weavy, c'est beaucoup mieux niveau BDD, même si c'est très loin d'être parfait, mais par contre quand tu repasses derrière du spécifique SDK... bah... t'as intérêt à sortir le masque, les palmes et le tuba de ton sac, et espérer que le gars qui a mis le truc en place n'était pas trop vieux ni trop autiste (malheureusement souvent c'est les deux à la fois, ça pique) ! Et la plupart du temps, on va bien moins loin que ce qu'on pouvait faire "facilement" avec Generix ou Update.
Par contre derrière, faut pas être cardiaque quand tu regardes ce qu'il se passe dans la base de données
On ne jouit bien que de ce qu’on partage.
Il y avait aussi le CRM que MS a racheté il y a longtemps maintenant (Dynamics) qui était une collection de mauvaises pratiques SQL-Server.
J'espère qu'ils ont réussi à s'auto-consulter depuis !
Email : http://scr.im/waldar
Magnifique
Ca me rappelle une SSII (connue sur la place) qui se vendait comme experte en SGBDR et dont les intervenants ne savaient même pas ce qu'était le catalogue ni ce qu'était un explain
Comme cette société avait été désignée comme sous-traitante pour des développements par le client chez lequel j'intervenais, et que le sujet concernait des traitements particulièrement sensibles aux performances. J'avais du former les "experts"
Si je me souviens bien, j'ai formé le directeur technique de GENERIX à SQL Server il y a près de 20 ans pour leur passage d'Oracle à SQL Server... Et quand j'ai vu la base, j'ai été horrifié !
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Tu rajeunis
Email : http://scr.im/waldar
[mode digression]
Juste pour la forme, une requête exécutée chez un client par Aurea.CRM pour afficher la liste des sociétés participantes à une affaire :
Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
Bon, après, à la décharge de l'éditeur, la requête est générée à partir du paramétrage de leurs règles très complexes... cependant, quand je fois des ID en dur dans le code, je ne peut qu'avoir pitié du pauvre optimiseur de SQL Server qui se paluche la compilation de la même requête X fois car elle n'est pas suffisamment paramétrée (car elle est paramétrée, vous verrez, y'a un "?" qui se balade au milieu !)
[/mode digression]
On ne jouit bien que de ce qu’on partage.
Merci à tous pour vos contributions
Je clôture le sujet, rapport en cours de finalisation
Bonjour,
Je reviens sur certaines pistes évoquées
Ok, mais le chantier pour initialiser l'existant risque d'être dissuasif
Ou plutôt toutes les tables volumineuses, disons 10 millions de lignes et plus ?
Par unité de temps, c'est à dire ?
Question subsidiaire : y a-t-il un site sur lequel on peut comparer les fonctionnalités et limites des différentes versions et éditions de SQL-server
(le passage à une édition payante n'étant pas gagné, je voulais notamment vérifier si certaines versions d'éditions express autorisent les index CSI)
Et alors ? avec des raisonnement comme ça ojn ne construit jamais rien...Bonjour,
Je reviens sur certaines pistes évoquées
Ok, mais le chantier pour initialiser l'existant risque d'être dissuasif1 million maintenant = 10 millions plus tard !
Ou plutôt toutes les tables volumineuses, disons 10 millions de lignes et plus ?
par mois, ou trimestre ou années...
Par unité de temps, c'est à dire ?
Express 352 Mo... autrement dit rien.
Question subsidiaire : y a-t-il un site sur lequel on peut comparer les fonctionnalités et limites des différentes versions et éditions de SQL-server
(le passage à une édition payante n'étant pas gagné, je voulais notamment vérifier si certaines versions d'éditions express autorisent les index CSI)
mais Web, oui ! 6 Go
A +
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
* * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager