SQL 2000 Backup history löschen

Bei jedem Backup einer DB wir ein Eintrag in der msdb erstellt für die Backup history. Nach ein par Jahren wird die msdb sehr gross und bei einem Restore über das GUI können über 15Min vergehen bis der Dialog er scheint. Mit der Store Procedure von Microsoft sp_delete_backuphistory ist es unmöglich mehrere Jahr oder auch nur Monate aus der msdb zu löschen. Tara Kizer hat ein viel effizienteres Script erstellt. So könnte ich 3 Jahre von 50 DBs ohne Probleme löschen.

CREATE PROC isp_DeleteBackupHistory(@DaysToRetain int)AS
SET NOCOUNT ON
DECLARE @Err intDECLARE @rc int
BEGIN TRAN
DELETE FROM msdb..restorefile FROM msdb..restorefile rf INNER JOIN msdb..restorehistory rh ON rf.restore_history_id = rh.restore_history_id INNER JOIN msdb..backupset bs ON rh.backup_set_id = bs.backup_set_id WHERE bs.backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..restorefilegroup FROM msdb..restorefilegroup rfg INNER JOIN msdb..restorehistory rh ON rfg.restore_history_id = rh.restore_history_id INNER JOIN msdb..backupset bs ON rh.backup_set_id = bs.backup_set_id WHERE bs.backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..restorehistory FROM msdb..restorehistory rh INNER JOIN msdb..backupset bs ON rh.backup_set_id = bs.backup_set_id WHERE bs.backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit SELECT media_set_id, backup_finish_date INTO #Temp FROM msdb..backupset WHERE backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..backupfile FROM msdb..backupfile bf INNER JOIN msdb..backupset bs ON bf.backup_set_id = bs.backup_set_id INNER JOIN #Temp t ON bs.media_set_id = t.media_set_id WHERE bs.backup_finish_date < (GETDATE() - @DaysToRetain)
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..backupset FROM msdb..backupset bs INNER JOIN #Temp t ON bs.media_set_id = t.media_set_id
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..backupmediafamily FROM msdb..backupmediafamily bmf INNER JOIN msdb..backupmediaset bms ON bmf.media_set_id = bms.media_set_id INNER JOIN #Temp t ON bms.media_set_id = t.media_set_id
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit DELETE FROM msdb..backupmediaset FROM msdb..backupmediaset bms INNER JOIN #Temp t ON bms.media_set_id = t.media_set_id
SET @Err = @@ERROR
IF @Err <> 0 GOTO Error_Exit
COMMIT TRAN
SET @rc = 0
GOTO isp_DeleteBackupHistory_Exit
Error_Exit:
ROLLBACK TRAN
SET @rc = -1
isp_DeleteBackupHistory_Exit:
DROP TABLE #Temp
SET NOCOUNT OFF
RETURN @rc
GO

Im Blog ist auch eine Version für SQL 2005 verfügbar:
http://weblogs.sqlteam.com/tarad/archive/2004/07/02/1704.aspx

MCMS 2002 100% CPU Load - zu viele Postings

Beim Deployment von Content im Microsoft CMS 2002 wird bei jedem deployment eine neue archiv Version des Content erstellt. So wird die Live DB immer grösser und kann dazuführen, dass der CMS Server überlastet ist. Da das CMS bei jedem Request alle Postings duchsuchen muss, auch die Archivierten. Wir hatten CMS Server, da war die CPU Last immer auf 100% und so war die Website nicht erreichbar.

Zum feststellen wie viele Postings im CMS vorhanden sind, kann dies SQL Query ausgeführt werden:

Select type, Count(*), GETDATE()
from scmcms.dbo.node
group by type

hier noch die Node Typen:
Type Name
1 Server
4 Channel
16 Postings
64 Ressourcen Folders
256 Ressourcen
16384 Template Gruppe
65536 Template
1048576 Administrator
2097152 Archive Folder, Deleted Items, Folder
524288 Rollen
1048576 Berechtigungs Gruppen

Die archivierten Postings können über den Sitemanager -> Tools -> Clear Revision History gelöscht werden. Leider funktioniert dies nicht immer, da schon zu viele archivierte Postings in der DB sind. Bei mir mit 27000 Postings und 97000 Ressourcen konnte ich nicht einmal ein Monat löschen. Zum Glück hatten dies Problem auch schon andere und kann gelöst werden mit dem ersetzten der Store Procedure PurgeRevisionsByDate.
http://support.microsoft.com/kb/899027/en-us

Danach konnte ich doch 4 Monate auf einmal löschen. Zu beachten ist das Transaction Log der DB dies wachst massiv bei dieser Löschaktion.

Der KB Artikel zum warten einer MCMS DB:
http://support.microsoft.com/kb/836646/en-us

stsadm langsam, Publisher's CRL

Es gibt MOSS Server die haben keine Internet zugriff, auch nicht über einen Proxy. So wird der ganze MOSS Server sehr langsam. Am besten ist der Effekt mit stsadm zu sehen. Nur der Aufruf ohne Parameter dauert 30s.
Wenn die SharePoint DLL's geladen werden versucht der SharePoint im Internet auf http://crl.microsoft.com/ oder http://crl.verisign.com/ zu zugreifen. Tja, und ohne Internet Verbindung wartet der SharePoint auf den Timeout.

Es gibt verschiedene Workarounds dies zu Lösen:

1. Host Eintrag setzen auf 127.0.0.1 für die zwei URL's. (Funktioniert nicht immer)
2. Proxy Server einsetzten und mit proxycfg -p 192.168.0.1:8080 konfigurieren
3. Disable im IE Tools>Internet Options>Advanced>Check for Publisher's certificate revocation.
4. Die CRL's downloaden und Importieren
   Download:
   http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
   http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
   Add them:
   certutil -addstore CA CodeSignPCA.crl certutil -addstore CA CodeSignPCA2.crl

Wir haben uns für Variante 3 entschieden, so haben wir auch mit weiteren Applikationen zB. SQL Management Studio keine Probleme.

Da ja MOSS meistens unter einem Service Account betrieben wird, ist es wichtigs dass auch diese die CRL (Client Revocation List) nicht übers Internet prüfen wollen. Da die Einstellungen für den IE nur für den Aktiven User gelten habe ich ein Script erstellt, dass die Settings auf allen Usern auf dem Server setzt.

Const HKEY_USERS = &H80000003
SetAllUsersRegKey
"Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software
Publishing\State",146944,"REG_DWORD"
Sub SetAllUsersRegKey(sKeyName,sData,sType)
Dim oShell, sKey, oReg,
sSubKey,aRegKeys,aDesktopKeys

Set oShell = CreateObject("Wscript.Shell")

Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
oReg.EnumKey HKEY_USERS, "", aRegKeys

For Each sSubkey In aRegKeys oReg.EnumKey
HKEY_USERS, sSubkey & "\Control Panel\Desktop", aDesktopKeys

If Not IsNull(aDesktopKeys) Then

Wscript.Echo sSubkey & "\" & sKeyName,sData,sType
oShell.RegWrite "HKEY_USERS\" & sSubkey & "\" & sKeyName,sData,sType

End If

Next
End Sub

Hier weiter Blogeinträge zu diesem Thema:
http://paulhorsfall.co.uk/archive/2007/05/27/Stsadm.exe-and-iisreset-Slow-Behind-Proxy-on-SharePoint.aspx

http://jritmeijer.spaces.live.com/blog/cns!8A48A27460FB898A!965.entry

AddSchedulingJobDefinitions failed beim Site erstellen

Wir haben eine neue Web Application erstellt mit eigenem Service Account und Custom Features und Layouts. Im Templatepicker haben wir unser Template gewählt und OK. Das Template wurde gesetzt aber es folgte die Meldung Access denied. In den ULS war der folgende Eintrag.

AddSchedulingJobDefinitions failed. System.Security.SecurityException: Access denied. at
Microsoft.SharePoint.Administration.SPPersistedObject.Update()
....

Da der Application Pool nicht unter dem Central Administration Pool Accout konfiguriert ist, hat der Account keine Rechte den Job zu erstellen für die Features zu aktivieren. Da dies nur einmal beim erstellen aktiviert wird kann dies mit einem Workaround gelöst werden.

1. Im IIS Admin properties der Web Application öffnen
2. Im Home Directory den Application Pool auf den Central Administration Pool setzten
3. iisreset
4. Site Template wählen (features aktivieren)
5. Den Application Pool wieder zurück setzten

Ähnliches Problem habe ich hier gefunden, sprich die Lösung:

http://msmvps.com/blogs/obts/archive/2007/01/30/528982.aspx

Ausschalten vom UAC Vista Black Screen

Vista UAC sollte ja nicht ausgeschltet werden. Aber wenn jede Anfrage des Administrator-Account und Password nur schon länder 5 sec dauert bis die Anmeldebox da ist nervt dies schon.
Zum Glück kann das verdunkeln des Bildschirms ausgeschaltet werden in der Policy.

Run secpol.msc Security Settings > Local Policies > Security Options
dort suchen nach "User Account Control: Switch to the secure desktop when prompting for elevation" und auf disable stellen.

Voilà, die Anmeldebox erscheint Blitzschnell :-)

TrustedInstaller braucht 90% CPU unter Vista

Auf meinem Vista ist nach dem Aufstarten oder nach dem ich den Media Player gestartet habe die CPU auslastung immer gegen 100%. Im Taskmanager ist rasch ersicht, dass dies der TrustedInstaller Prozess ist der die Last generiert.
Was ist die TrustedInstaller.exe?
Kurz ausgedrückt es ist der Prozess der die "wichtigen" System Ressourcen überwacht die mit dem OS installiert wurden. Diese werden geschützt, in dem nur noch der Benutzer NT Service\TrustedInstaller berechtigt ist auf den System files, folders und registry keys. Der TrustedInstaller wird jedes mal gestartet wenn das Windows Update läuft oder wenn "Problem Reports and Solutions" Service nach neuen Solutions sucht. Hier ist auch die Ursache des Problems (was er eigentlich versucht zu lösen).

Beim Aufstarten von Vista wird der Update Service gestartet und dieser sucht neue Updates also der TrustedInstaller wird aktiv.

Jeder Multimaedia PC hat sicher ffdshow installiert. Leider gibt es hier Probleme mit dem Media Player und es wird ein Problem Report erstellt. Diese Reports bleiben im "Problem Reports and Solutions" bis sie gelöscht oder gelöst werden. Wenn ein Report noch vorhanden ist, sucht Vista immer wieder nach Lösungen und der TrustedInstaller wird gestartet. Dies kann auch mitten in einem Film vorkommen und bei meinem nicht hoch performaten PC bleibt das Bild stehen.

Lösung:
Unter Start > Control Panel > Classic View > Problem Reports and Solutions > Clear Solution and Problem History > "bestätigen des löschen" > Control Panel schliessen

Ich habe jetzt sogar unter Problem Reports and Solutions > Change Settings > Advanced settings das "problem reporting" ausgeschaltet.

Wer die Berechtigungen der System files ändern will sollte diesen Blog Eintrag lesen:
http://blogs.msdn.com/irenak/archive/2007/01/30/sysk-277-how-to-bring-back-the-trustedinstaller.aspx

Spb Shell 2.0

Für die Windows Mobile Devices ist die Version 2.0 der Spb Shell erschienen. Diese erweitert die Windows Mobile Gräte zum Teil mit der Gestensteuerung, so wie dies beim HTC Touch oder beim iPhone implementiert ist.
Auf der Spb Homepage ist ein Video mit dem Funktionsumfang der Shell.
http://www.spbsoftwarehouse.com/products/mobileshell/?de