Generell kenn ich zwei Strategien zur Serverabsicherung
A) halbwegs wichtiges System. Dann l�uft ein Hotbackup Server neben dran, der die Daten vom Lifesystem repliziert bekommt. Da es ein transactionsbasiertes System ist, ist das ja machbar. Es werden nur die �nderungen �bertragen. B) nicht so wichtiges System (oder Sparflammensystem), dann wird das Plattensystem relativ ausfallsicher gestaltet (RAID 5 ist da eine Standardl�sung). Zum Wiederaufsetzen eines neuen Systems oder einer Kopie existieren vollst�ndige Scripts, die die DB mit allen Komponenten anlegen. Und die Daten selbst werden mit BCP geladen bzw. zum Backup gesichert. Beim Scripten hilft �brigens der Enterprise Manager gewaltig. Was ich nicht wirklich kenne sind die ganzen neuen HA (high availability) options. Bin zwar ein paar Jahre nicht mehr direkt in dem Gesch�ft; wohl aber User von wichtigen Company-Systemen. Ein ausgefallener SQL Server ist mir noch nie untergekommen. In einem Rechenzentrum mit ca 120 Servern (File, Mail, Print, SQL, etc.). Das worst case Scenario hatten wir vor vielen Jahren mit einem OS/2 SQL Server. Im Plattensystem war das Verzeichnis rekursiv endlos tief geschachtelt. Device files gab es �berhaupt keine mehr. Aber der Server lief und spuckte Daten aus. Tags�ber hektische Betriebsamkeit; in der Nacht dann unerlaubterweise das System auf einem NT Rechner neu aufgesetzt, Daten kopiert und am n�chsten Tag die Schultern eingezogen ;-) ----------------- Thema Doku Ich denke Du hast in der Praxis viel mehr mit Datenbankinkonsistenzen (echte, die mit dbcc auffallen und unechte, weil etwa Daten keinen Sinn ergeben), �bergelaufenem Transaction Log (glaub das ist in den neueren Versionen gefixt), Indexoptimierung, etc. zu tun als mit Datenbankrestaurierung. Um trotzdem beim Restore zu bleiben: ich w�rde ich mir die Originaldoku reinziehen. SQL Online sollte gen�gend Lesestoff zum Thema bieten. Genauso die MSDN (etwa http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?conte ntid=28000409) oder TechNet (etwa http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodt echnol/sql/maintain/operate/opsguide/default.asp - dort spezifisch das Chapter 7: Problem and Incident management). Auch relevant in dem Zusammenhang: http://www.microsoft.com/sql/techinfo/reskit/default.asp Oder groups.google.de und dort mal suchen, was andere an [schlechten] Erfahrungen gesammelt haben. Und zuletzt ist vielleicht eine Aussage von Gartner (oder war es ITIL?) interessant: Die Ursache von Systemausf�llen ist in 70% oder 80% der F�lle in den Bedienmannschaft (people) oder den Prozessen (processes) begr�ndet. Nur der Rest ist Hard- oder Softwareausfall. -- Viele Gr��e Hubert Daubmeier -----Original Message----- From: Karin WALTER [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 03, 2001 1:28 PM To: AspGerman Kaffeehaus Subject: [aspdecoffeehouse] AW: SQL Server 7.0 Import Funktion Hallo Hubert, danke Dir und auch Claudius erst mal f�r den Tipp. Aber ich glaube fast mein Problem liegt daran das beim Import die System Tabellen nicht wirklich upgedatet werden und daher die Benutzer nicht erkannt werden, obwohl ich das auch nicht vestehe. Wie es scheint muss ich mir da noch ein paar B�cher besorgen, in meinen ist das nicht so ganz klar beschrieben. Da steht zum Teil immer nur wie es gemacht wird, ich m�chte aber wissen was die einzelnen Optionen genau bewirken. Wnn jemand gute Links zur Import/Export und Backup/Restore zum SQL Server 7.0 kennt, w�re ich aber auch dankbar (Die MS Links kenne ich so ziemlich alle). Was mich auch interessieren w�rde ist, wie eure Disaster Recovery Strategien bzw. Pl�ne in Bezug auf SQL-Server aussehen? sch�nes Wochenende w�nsche ich allen lg. Karin | [aspdecoffeehouse] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
