Im April und Mai veröffentlichte Microsoft kumulative Updates für SQL Server 2008 und 2008 R2 (ich habe hier und hier darüber gebloggt). Sie sind:
| Zweig | Original-CU | Build # | KB-Artikel | Datum hinzugefügt |
|---|---|---|---|---|
| SQL Server 2008 SP3 | CU Nr. 11 | 10.00.5840 | KB #2834048 | 2013-05-20 |
| SQL Server 2008 R2 SP1 | CU Nr. 12 | 10.50.2874 | KB #2828727 | 2013-04-15 |
| SQL Server 2008 R2 SP2 | CU Nr. 6 | 10.50.4279 | KB #2830140 | 2013-04-15 |
Irgendwann danach, wie es aussieht, wurden am nächsten Tag beide Downloads zurückgezogen, angeblich aufgrund eines Indexbeschädigungsproblems (wenn Sie dem Kommentar zum Release Services-Blogpost für CU #6 glauben) oder aufgrund eines Problems mit w3wp .exe (wenn Sie glauben, dass das Label auf dem Hotfix direkt im Artikel zu CU Nr. 6 selbst gepostet wurde). Oder vielleicht beides. Zumindest können Sie eine Regression sehen, die eine Indexbeschädigung oder eine massive Abweichung der Indexgröße beinhaltet, wenn Sie einen gruppierten Index online neu erstellen und der Plan einen nicht gruppierten Index beinhaltet. Ich habe keine Repro zur Hand.
Am 13. Juni wurden beide Artikel mit neuen Versionen der kumulativen Updates aktualisiert, die dieses Symptom nicht mehr aufweisen (kommt Ihnen das bekannt vor?). Und sie wurden am 17. Juni erneut aktualisiert. Wenn Sie also heute herunterladen, erhalten Sie tatsächlich:
| Zweig | Aktualisiertes CU | Neue Build-Nr. | KB-Artikel | Aktualisierungsdatum |
|---|---|---|---|---|
| SQL Server 2008 SP3 | CU Nr. 11 | 10.00.5841 | KB #2834048 | 2013-06-17 |
| SQL Server 2008 R2 SP1 | CU Nr. 12 | 10.50.2875 | KB #2828727 | 2013-06-17 |
| SQL Server 2008 R2 SP2 | CU Nr. 6 | 10.50.4285 | KB #2830140 | 2013-06-17 |
Bitte überprüfen Sie @@VERSION . Wenn es 10.00.5840, 10.50.2874 oder 10.50.4279 meldet, gehen Sie bitte erneut zum Download und wenden Sie das relevante kumulative Update für Ihren Zweig erneut an. Besser noch, wenn Sie 2008 R2 verwenden, lesen Sie bitte meinen Beitrag, in dem ich neue CUs für die 2008 R2-Zweige ankündige:
| Zweig | CU | Build # | KB-Artikel | Datum hinzugefügt |
|---|---|---|---|---|
| SQL Server 2008 R2 SP1 | CU Nr. 13 | 10.50.2876 | KB #2855792 | 2013-06-17 |
| SQL Server 2008 R2 SP2 | CU Nr. 7 | 10.50.4286 | KB #2844090 | 2013-06-17 |
In solchen Fällen wünschte ich wirklich, wirklich, sie würden ein neues, kumulatives Out-of-Band-Update veröffentlichen (das ist jetzt kein Problem für R2, bleibt aber ein Problem für 2008 SP3-Kunden für einen weiteren Monat oder so). Wie viele Leute schauen sich den CU-Artikel noch einmal an, nachdem sie ihn heruntergeladen, installiert und einem Regressionstest unterzogen haben? Testet jeder Regressionstest einen vollständigen Satz von Online-Wiederherstellungen, eine Operation, die wahrscheinlich nicht so oft vorkommt? Ich denke, viele Benutzer werden dieses Update einfach nicht sehen und stehen kurz davor, das Symptom zu erleben – es gibt einfach nicht genug Sichtbarkeit, wenn sie die Versionen, die die Download-Links liefern, stillschweigend austauschen.
[Quergepostet auf sqlblog.org]
