Sancho_hl

Hallo,

 

Das Phänomen habe ich schon mal gehabt. Hier sind die Tlog Sicherungen mit den Datenbank Sicherungen kollidiert. So wurden dann eben nur die Datenbanken gesichert, die gerade nicht von der Tlog Sicherung betroffen waren. Ggf. Da mal die Zeiten anpassen.

 

Weiter solltest Du dies besser über Wartungspläne machen. Das Logging funktioniert hier besser und Du kannst dies auch besser steuern.

 

Als nächstes solltest Du nicht einfach die Indizes Neu aufbauen oder reorganisieren, schau Dir besser mal die Konzepte zu dynamischer Indexwartung an.

 

Grüsse.

Hi,

danke für deine Antwort.

Habe jetzt 2 zusätzliche Skripte geschrieben. Eines, welches vor dem Backup der DBs die Transaktionssicherung deaktiviert und eines, welches sie danach wieder aktiviert.

Den Zeitplan so anzupassen, dass in dem Zeitraum nicht gesichert wird, ist schwer, da der Backupserver für die Sicherung einen Zeitraum und keinen festen Zeitpunkt zugewiesen bekommen hat.

Mit der dynamischen Indexwartung werde ich mich dann auch mal beschäftigen.

Gruss

Sancho

Ok, ich danke dir erstmal für deine Hilfe.

Werde die Ausgabe mal erweitern und mich dann, sobald das Problem wieder Auftritt, nochmal melden :)

Gruß

Sancho

Moin,

 

wenn eine der Datenbanken nicht gesichert wurde, was für ein Sicherungsdatum gibt sie denn dann in ihren Eigenschaften an? Vielleicht ist das Backup als solches ja korrekt verlaufen, aber die Datei wird hinterher durch irgendwas gelöscht.

 

Gruß, Nils

Bei allen DBs, die nicht gesichert wurden, wird der 26.12. angegeben.

Stehen müsste dort allerdings der 27.12.

Hier die Einstellungen für zumindest eine der DBs

Ähm ja sorry.

Fehlermeldungen sind, wie gesagt, keine vorhanden.

Das Script sieht so aus:

DECLARE @name VARCHAR(50) -- database name
DECLARE @path VARCHAR(256) -- path for backup files
DECLARE @fileName VARCHAR(256) -- filename for backup
DECLARE @fileDate VARCHAR(20) -- used for file name
DECLARE @dbsubdir VARCHAR(256) -- db subfolder to create

SET @path = 'D:\SQLbackup\Sicherung'

SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112)

DECLARE db_cursor CURSOR FOR
SELECT name FROM master.dbo.sysdatabases
WHERE name NOT IN ('master','model','msdb','tempdb')

OPEN db_cursor
FETCH NEXT FROM db_cursor INTO @name

WHILE @@FETCH_STATUS = 0
BEGIN
      SET @dbsubdir = @path + '\' + @name
      EXECUTE master.dbo.xp_create_subdir @dbsubdir
      SET @fileName = @dbsubdir + '\' + @name + '_' + @fileDate + '.BAK'
      BACKUP DATABASE @name TO DISK = @fileName
      PRINT 'Backup: ' + @name + '_' + @filedate + CHAR(13)

      FETCH NEXT FROM db_cursor INTO @name
END

CLOSE db_cursor
DEALLOCATE db_cursor

und es wird aufgerufen vom Backup-Server durch eine Batch mit folgendem Inhalt:

set DBSERVER=xxx
set DBUSER=sa
set DBPASSWD=xxx

osql.exe -S %DBSERVER% -U %DBUSER% -P %DBPASSWD% -i "C:\xxx\xxx\xxx\backup_user_db.sql"

Nach dem Job folgen dann noch reorganize bzw. reindex und update der statistiken. Diese laufen aber komplett durch laut logfile des backup servers.

Da ich, was SQL angeht, nicht sehr erfahren bin:

Das das Script nicht vollständig durchläuft kann sehr gut sein, aber warum? :)

Der Backup-Server würde auf jeden Fall eine Meldung ausgeben, wenn ein Job abgebrochen wird.

Ist es ein Problem für den SQL-Server, wenn sich DB- und LOG-Backup überschneiden?

Im Eventlog sind Meldungen über erfolgte Sicherungen vorhanden. Natürlich nicht von den DBs, die "vergessen" wurden.

Was mir aufgefallen ist, für eine bestimmte DB "X" sind mehrfach Meldungen vorhanden:

CHECKDB für die 'X'-Datenbank wurde am 2012-12-03 00:45:33.450 (Ortszeit) ohne Fehler abgeschlossen. Diese Meldung dient nur zu Informationszwecken. Es ist keine Benutzeraktion erforderlich.

und

'X'-Datenbank wird gestartet

Edit:

Die oben genannten Einträge sind mehrfach vorhanden, für die DBs, deren Sicherung nicht gelaufen ist und deren Wiederherstellungsmodell auf "Einfach" steht. Fehler oder Warnungen liegen aber nicht vor.

Die DBs, deren Wiederherstellungsmodell auf "Vollständig" steht tauchen im Eventlog nicht auf, mit Ausnahme der Meldungen von der LOG Sicherung.

Moin,

ich habe hier das Problem, das sporadisch (so ca. 4-5 mal im Monat) nicht alle Datenbanken gesichert werden. Es ist unterschiedlich welche DBs im Backup ausgelassen werden.

Der SQL-Server ist ein MSSQL Server 2005 SP4.

Das Wiederherstellungsmodell ist bei einigen DBs "Vollständig", bei anderen "Einfach".

Es wird täglich ein Full-Backup von jeder DB gemacht, bei den DBs die auf "Vollständig" eingestellt sind, wird stündlich ein LOG-Backup durchgeführt.

Nach dem Backup wird entweder ein reorganize oder rebuild des index durchgeführt.

Gesichert wird per tsql script.

Etwas genauer sieht die Sicherung so aus:

Der Backup-Server (bacula) führt das Backup Script für alle DBs aus, dann werden die .bak und .trn dateien auf den Backup-Server kopiert und komprimiert. Danach wird ein reorganize oder rebuild vom index durchgeführt, dann ein Update der Statistiken.

Bisher konnte ich das Problem nicht lokalisieren, es werden keine Fehler ausgegeben.

Ich hoffe, das mir jemand weiterhelfen oder einen Denkanstoß geben kann :)

Gruss

Sancho

Moin,

erstmal zum System:

- SQL Server 2005 Standard SP4 (standalone Server, SQL only)

Backupstrategie:

User DBs: tägliche Vollsicherung inkl. Statistiken aktualisieren und Index reorganize

System DBs: jeden Sonntag Vollsicherung inkl. Statistiken aktualisieren und Index reorganize

Transaktionsprotokoll: Stündlich für jede DB

Die Sicherung der DBs läuft per SQL-Skript und nicht über Wartungspläne, da der Backupserver das Skript vor der Dateisicherung anstößt.

Die Sicherung des Transaktionsprotokolls läuft über einen Wartungsplan

Also DB Backup -> auslagern der .bak und .trn dateien -> Dateisicherung

Dazu jeden ersten Sonntag im Monat ein Integritätscheck, Index Rebuild und Verlaufscleanup.

Zum eigentlich Problem:

Eine der Echtsystemdatenbanken ist ca. 13 GB groß, welches auch nicht weiter schlimm ist.

Das Transaktionsprotokoll der DB ist ca. 11 GB groß, was eindeutig zu viel ist.

Bisher gemacht wurde:

Backup Log + Checkpoint und das Transaktionsprotokoll auf 5 GB verkleinert. -> der nächste automatische Backup Log Job hat das ganze dann auf eine Größe von ~ 200 MB gebracht.

Gestern Nacht lief dann auch alles bestens.

Nun habe ich mir das LDF File der DB heute wieder angeschaut und es ist wieder auf 11 GB angewachsen.

Jede Nacht (ausgenommen Gestern) um 1 oder 2 Uhr ist die Sicherung des Transaktionsprotokolls 11 GB groß (DB Backup ist gegen 21 Uhr abgeschlossen), zu jeder anderen Stunde nur ein Bruchteil davon.

Ein Query zeigt mir log_reuse_wait "2" und log_reuse_wait_desc "LOG_BACKUP"

Nun zur eigentlich Frage: Warum wächst das Log immer auf diese enorme Größe (hängt ja wahrscheinlich mit dem Query zusammen) und wie kann ich dies verhindern?

Hi,

sorry für die späte Antwort.

Die User melden sich mit Ihrem Domänenkonto an, die PCs sind in der Domäne, für die Verbindung wird remotefx benutzt, was von Server 2008 R2 ab SP1 unterstützt wird.

Was mich wundert ist die Tatsache, dass die IGELs sich vorher immer problemlos verbinden konnten.

Moin,

wir hatten heute morgen das Problem mit dem Terminalserver eines Kunden.

Und zwar konnten sich Windows PCs noch mit dem TS (Server 2008 R2) verbinden, Thinclients (hier IGEL) wurde die Verbindung doch untersagt.

Der Handshake wurde gemacht und dann wurde die Verbindung sofort gedroppt. Fehlermeldung: PDU Connection Error 0x5 - No External Backing Store available

Nach langem hin und her haben wir dann in der Konfiguration des Remotedesktop-Sitzungshostservers unter RDP-TCP Einstellungen den Haken bei "Nur Verbindungen von Computern zulassen, auf denen die Authentifizierung auf Netzwerkebene ausgeführt wird." entfernt.

Da wir uns absolut nicht erklären können, wie dieses Problem zustande gekommen ist, wollte ich mal nachfragen ob es hier Erfahrungswerte dazu gibt?

Der Server wurde nicht angefasst seit Freitag, das einzige was getan wurde, war die deinstallation von WSUS, was mit den Thinclients ja aber eigentlich nichts zu tun hat. Ach so, der "Windows Update Agent" hat sich selbstständig aktualisiert, ansonsten sind die Updates so eingestellt, das wir den Installationszeitpunkt manuell festlegen.

Hm, du hast während des experimentierens nicht zufällig Internet Connection Sharing aktiviert? ;)

Hast du mal mit dem netmon den broadcast überwacht? Kommt da überhaupt was an bzw. geht was raus?

TMG ist ja nun grad das aktuellste von Microsoft. Wie wäre es einfach mit nem ISA Server?

Problem hat sich gelöst, im DHCP war die Routeroption falsch eingestellt ;)

Und im 2k3 Modus lief es halt auch schon. Wir haben praktisch die DCs von 2003 nach 2008 R2 migriert und als letzte Handlung Exchange zur 2007er Version auf den zweiten DC repliziert.

Moin,

ich hatte einen DC (2003 SP2) mit Exchange 2003 laufen. Dieser wurde nun durch einen 2008er R2 mit Exchange 2007 ersetzt.

Die Migration von Exchange lief problemlos, jedoch ist es jetzt nicht mehr möglich verschlüsselte E-Mails zu senden und auf andere Addressbücher zuzugreifen. Fehlermeldung ist entweder "Keine Verbindung zum LDAP-Verzeichnisserver möglich (81)" oder "LDAP-Verzeichnis ist nicht verfügbar (52)". Dies betrifft alle Rechner in der Domäne.

Benutzer aus anderen Domänen können allerdings schon auf mein Addressbuch zugreifen.

In der Domäne laufen 1 Router, 1 DC (prim. DNS, DHCP, IIS, IAS usw.) und besagter DC (sek. DNS, Exchange 2007). Beide DCs sind GC. Alle auf 2008 R2. Clients sind sowohl XP als auch Windows 7 Rechner. Habe auch Outlook Express und Live Mail getestet ;)

Ich habe schon etliche Seiten im Netz durchforstet bisher aber nicht erfolgreich. Hoffe mir kann hier jemand helfen.

Freundliche Grüße :)

PS: LDAP-Verzeichnisse löschen und neu anlegen brachte keine Besserung.