none
SQL Server 2008 R2 - Service Pack einspielen RRS feed

 > 

  • Allgemeine Diskussion

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo,
    ich bin gerade am durchspielen eines Szenarios für SQL 2008R2, welche Edition usw.
    Meine Frage wäre:

    Wie ist euer vorgehen, wenn ihr einen neuen ServicePack im SQL Server einspielt ?

    Einfach einspielen und hoffen das er geht ? Oder macht das ganze aus der Erfahrung heraus so wenig Probleme,
    das man das bedenkenlos tun kann?

    Hat man mit Enterprise Edition dafür vielleicht eine inteligentere Lösung gefunden ?

    Danke
    Markus

    Montag, 10. Oktober 2011 12:45
    |

Alle Antworten

  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Markus,

    mit hoffen ist es sicher nicht getan. Zum Einspielen eines SP gehe ich wie folgt vor:

    Einrichten einer Testumgebung mit der aktuell verwendeten Version
    Einspielen der zu testenden Datenbanken
    Einspielen des SP
    Test der verwendeten DBs

    Sind alle Tests erfolgreich gelaufen wird ein Ablaufplan erstellt mit entsprechenden Downzeiten in denen das SP eingespielt wird. Dazu wird dann ein komplettes DB Backup erstellt, dann erfolgt das Einspielen des SP, anschließend wiede Freigabe des Servers.

     

    Gruß Thomas

    Montag, 10. Oktober 2011 15:04
    |
  • Discussion
    Anmelden
    0
    Anmelden

    OK vielen Dank für deinen Beitrag.

    Ich habe nur gehofft, das jemand eine Idee hat, wie man dies verbessern, sprich vereinfachen kann.
    Wenn man ein 2te Instanz auf dem Server installiert, der man dann den ServicePack gibt, wäre zwar möglich, aber
    auch nicht die eleganteste Lösung in Bezug auf die Datenbank tests.

    Ich habe auf dem Haupt SQL Server über 70 Datenbanken.

    Das wird nicht ganz so einfach immer die entsprechenden Ansprechpartner zu finden und dann die Applikation umzubauen, bzw die ODBC anders zu konfigurieren und und und....

    Ich habe mir sowas wie einen "ServicePack Testmodus" vorgestellt. Habe aber noch nie davon gehört. Deshalb mal meine Frage in die Runde.

    Gruß
    Markus

    Dienstag, 11. Oktober 2011 06:58
    |
  • Discussion
    Anmelden
    0
    Anmelden
    Das wird nicht ganz so einfach immer die entsprechenden Ansprechpartner zu finden und dann die Applikation umzubauen, bzw die ODBC anders zu konfigurieren und und und....

    Hallo Markus,

    eine Übersicht der Datenbanken mit den dazugehörigen Ansprechpartner samt Vertretern würde wohl Sinn machen. Vielleicht ist SP1 ein guter Ansatz um solch eine Übersicht zu erstellen.

    "Normalerweise" sollte ein SP ja Bugs beseitigen usw. aber endgültige Sicherheit hat man eben erst nach den Tests. Wichtig ist auf alle Fälle, dass vor dem Einspielen alle DBs gesichert sind, sollte eben doch was schief gehen.

    Guggeln nach +bugs +"sql server 2008 r2" +sp1 wirft immerhin noch über 45.000 hits raus.

    Falls Du zu Erkenntnissen kommst wäre ich auch an deinen Erfahrungen interessiert da SP1 hier bald auf mich zukommt.

    Gruß Thomas


    Dienstag, 11. Oktober 2011 12:12
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Ihr beiden,
    wir haben einen Entwicklungsserver für jede Version (2005, 2008, 2008 R2), der als erstes das ServicePack bekommt.
    Ein oder zwei Wochen später wird das ServicePack auf dem Abnahmesystem eingespielt.
    Weitere zwei bis vier Wochen später wird das ServicePack auf Produktion eingespielt.
    Dazwischen testen die Entwickler oder Fachabteilungen ihre Anwendungen.

    Es gibt keinen Aufwand für Neuinstallationen oder Abgleich von Konfigurationen, da die Entwicklungs-/Abnamesysteme auf dem aktuellen Stand sind.
    Zusätzliche Sicherungen sind nicht notwendig, da wir immer aktuelle Sicherungen haben.

    Wirkliche Probleme mit ServicePacks haben wir seit Version 7.0 nicht mehr gehabt. Die Summe der behobenen Bugs ist meiner Meinung nach auch immer größer, als die Menge neuer Bugs. Wenn man getestet hat, sollten einen neue Bugs erst mal kalt lassen. Andernfalls sind hier Workarounds und ggf. Hotfixe notwendig.

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu

    Dienstag, 11. Oktober 2011 12:36
    |
    Beantworter
  • Discussion
    Anmelden
    0
    Anmelden

    Vielen Dank Christoph.

    Wie hälst du die Datenbanken auf einer aktuellen Sicherung ?

    Machst du Logshipping ? oder einfach jeden Tag eine Sicherung und ein Restore auf dem Abnahmesystem ?

     

    Dienstag, 11. Oktober 2011 14:12
    |
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Markus,
    ich habe nicht gesagt, dass wir mit aktuellen Produktionsdaten auf der Entwicklung arbeiten. Das ist schon aus Datenschutzgründen nicht erlaubt.
    Auch können wir nicht die Datenmengen auf der Entwicklung bereitstellen, die wir in Produktion haben.
    Wir machen am Wochenende Vollsicherungen, unter der Woche differentielle Sicherungen und tagsüber Transaktionslog-Sicherungen. Also ganz klassisch.

    Ansonsten würde ich zum sporadischen Aufbau eines Referenz-Systems natürlich auf solche Sicherungen zurückgreifen, mit dem positiven Nebeneffekt, dass ich meine Sicherungsstrategie immer mal wieder überprüfen kann.

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu

    Mittwoch, 12. Oktober 2011 05:56
    |
    Beantworter
  • Discussion
    Anmelden
    0
    Anmelden

    Hallo Markus,
    gleich noch eine Anmerkung dazu!

    Wenn Du reproduzierbare Tests haben willst, die möglichst auch noch automatisch ablaufen, solltest Du auch einen genau beschriebenen Datenbestand haben. Produktionsdaten eignen sich nicht so gut für automatisierte Tests, obschon sie natürlich den Charme haben, auch solche unmöglichen Fälle abzudecken, auf die die Entwickler nie im Leben gekommen wären.

    Also schon aus diesem Grunde ist eine dedizierte Abnahmeumgebung mit speziellen Testfällen, die immer wiederhergestellt werden kann eine Voraussetzung für erfolgreiches Testen.

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP
    www.insidesql.org/blogs/cmu

    Mittwoch, 12. Oktober 2011 06:02
    |
    Beantworter