<?xml version="1.0" encoding="utf-8"?><!-- generator="b2evolution/6.11.7-stable" -->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>Frank Kalis - Neueste Kommentare auf Index Maintenance oder dm_db_index_physical_stats ist langsam</title>
		<link>https://www.insidesql.org/blogs/frankkalis/?disp=comments</link>
		<atom:link rel="self" type="application/rss+xml" href="https://www.insidesql.org/blogs/frankkalis/?tempskin=_rss2&#38;disp=comments&#38;p=2500" />
		<description></description>
		<language>de-DE</language>
		<docs>http://backend.userland.com/rss</docs>
		<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=6.11.7-stable"/>
		<ttl>60</ttl>
		<item>
			<title>admin in Antwort auf: Index Maintenance oder dm_db_index_physical_stats ist langsam</title>
			<pubDate>Tue, 22 Feb 2011 14:54:05 +0000</pubDate>
			<dc:creator><a href="http://www.insidesql.org/blogs/" title="Benutzerprofil anzeigen" class="login user nowrap" rel="bubbletip_user_1"><span class="identity_link_username">admin</span></a></dc:creator>
			<guid isPermaLink="false">c1159@https://www.insidesql.org/blogs/</guid>
			<description>Hallo Holger,

danke für das Feedback!
Ja, wir haben die anderen Werte ebenfalls beobachtet. Ich hätte vielleicht im Beitrag erwähnen, dass wir sämtliche Scanning Mode vorher ausprobiert und die Ergebnisse verglichen haben. Dabei war der Wert für avg_page_space_used_in_percent stets deutlich über 90.</description>
			<content:encoded><![CDATA[Hallo Holger,

danke für das Feedback!
Ja, wir haben die anderen Werte ebenfalls beobachtet. Ich hätte vielleicht im Beitrag erwähnen, dass wir sämtliche Scanning Mode vorher ausprobiert und die Ergebnisse verglichen haben. Dabei war der Wert für avg_page_space_used_in_percent stets deutlich über 90.]]></content:encoded>
			<link>https://www.insidesql.org/blogs/frankkalis/2011/02/02/index-maintenance-oder-dm_db_index_physical_stats-ist-langsam#c1159</link>
		</item>
		<item>
			<title> Holger Schmeling in Antwort auf: Index Maintenance oder dm_db_index_physical_stats ist langsam</title>
			<pubDate>Tue, 22 Feb 2011 07:32:06 +0000</pubDate>
			<dc:creator><span class="user anonymous" rel="bubbletip_comment_1157">Holger Schmeling</span></dc:creator>
			<guid isPermaLink="false">c1157@https://www.insidesql.org/blogs/</guid>
			<description>Hallo Frank,

ich bin ganz Deiner Meinung, was den mehr oder weniger bedenkenlosen Einsatz von fertigen Skripten angeht. Immerhin ist das ja auch Software und damit besteht eine gewisse Wahrscheinlichkeit für enthaltene Fehler :) Generell bin ich immer skeptisch, wenn man fertige Lösungen einsetzt ohne groß darüber nachzudenken, was da wirklich passiert. Dennoch ist vor allem das Skript von OH irgendwie allgegenwärtig, und ich denke auch, dass es gut ist - eben nur nicht in jedem Fall, womit wir wieder dabei wären, dass man überlegen muss, ob.
Aus meiner Erfahrung gibt es noch einen leidigen Punkt - und wahrscheinlich eine schlechte Nachricht für Dich. Ich hatte nun bereits mehrfach den Fall, dass ein Index nicht auf der Blatt-Ebene, sondern auf der darüberliegenden Ebene fragmentiert war. Die Auswirkung waren nicht ausreichend aufgefüllte Seiten in einer Nicht-Blatt-Ebene, und das hat letztlich die Tiefe des Indexbaumes um eins erhöht - sagen wir von drei auf vier. Jeder Index-Seek dauert also 25% länger. Hast Du neben dem Wert avg_fargmentation_percent einmal den Wert von avg_space_user_in_percent beobachtet? Leider bekommst Du diesen Wert nicht mit der Option &#039;LIMITED&#039; heraus - da musst Du zumindest &#039;SAMPLED&#039; verwenden.
Viele Grüße,
Holger</description>
			<content:encoded><![CDATA[Hallo Frank,

ich bin ganz Deiner Meinung, was den mehr oder weniger bedenkenlosen Einsatz von fertigen Skripten angeht. Immerhin ist das ja auch Software und damit besteht eine gewisse Wahrscheinlichkeit für enthaltene Fehler :) Generell bin ich immer skeptisch, wenn man fertige Lösungen einsetzt ohne groß darüber nachzudenken, was da wirklich passiert. Dennoch ist vor allem das Skript von OH irgendwie allgegenwärtig, und ich denke auch, dass es gut ist - eben nur nicht in jedem Fall, womit wir wieder dabei wären, dass man überlegen muss, ob.
Aus meiner Erfahrung gibt es noch einen leidigen Punkt - und wahrscheinlich eine schlechte Nachricht für Dich. Ich hatte nun bereits mehrfach den Fall, dass ein Index nicht auf der Blatt-Ebene, sondern auf der darüberliegenden Ebene fragmentiert war. Die Auswirkung waren nicht ausreichend aufgefüllte Seiten in einer Nicht-Blatt-Ebene, und das hat letztlich die Tiefe des Indexbaumes um eins erhöht - sagen wir von drei auf vier. Jeder Index-Seek dauert also 25% länger. Hast Du neben dem Wert avg_fargmentation_percent einmal den Wert von avg_space_user_in_percent beobachtet? Leider bekommst Du diesen Wert nicht mit der Option 'LIMITED' heraus - da musst Du zumindest 'SAMPLED' verwenden.
Viele Grüße,
Holger]]></content:encoded>
			<link>https://www.insidesql.org/blogs/frankkalis/2011/02/02/index-maintenance-oder-dm_db_index_physical_stats-ist-langsam#c1157</link>
		</item>
		<item>
			<title>admin in Antwort auf: Index Maintenance oder dm_db_index_physical_stats ist langsam</title>
			<pubDate>Thu, 17 Feb 2011 12:19:09 +0000</pubDate>
			<dc:creator><a href="http://www.insidesql.org/blogs/" title="Benutzerprofil anzeigen" class="login user nowrap" rel="bubbletip_user_1"><span class="identity_link_username">admin</span></a></dc:creator>
			<guid isPermaLink="false">c1156@https://www.insidesql.org/blogs/</guid>
			<description>Hallo Dirk,

danke fürs Feedback!

Ich kenne das Skript von Michelle und auch das von Ola Hallengren und habe vorher auch überlegt, ob ich nicht eines davon verwenden soll anstatt das Rad neu zu erfinden. Das &quot;Problem&quot; mit diesen Skripten jedoch ist, dass sie &quot;general-purpose&quot; sind und versuchen alle Eventualitäten abzudecken und damit auch Sachen, von denen ich weiss, dass wir sie sehr wahrscheinlich nicht in unseren Datenbanken haben werden (zum Beispiel LOB Spalten und/oder XML Indexes). Anfangs habe ich dann versucht, diese Spezialitäten aus den Skripten rauszunehmen, habe dann aber festgestellt, dass ich dafür länger brauche als was eigenes zu schreiben.

Ausserdem brauche ich das nur für 3 Datenbanken auf einem Server. Unsere Produktions-DBAs haben ihre eigenen Skripts, die sie auf allen ihren Servern laufen lassen.

Dein Ablauf klingt so wie unser war, bevor wir festgestellt haben, dass das Feststellen der Fragmentierung bei grösseren Tabellen richtig lange dauern kann. Abhängig von der Grösse Deiner Indexes würde ich das im Auge behalten, ob das mit dem Wartungsfenster so hinkommt oder wie uns, aus dem Ruder läuft. :-)</description>
			<content:encoded><![CDATA[Hallo Dirk,

danke fürs Feedback!

Ich kenne das Skript von Michelle und auch das von Ola Hallengren und habe vorher auch überlegt, ob ich nicht eines davon verwenden soll anstatt das Rad neu zu erfinden. Das "Problem" mit diesen Skripten jedoch ist, dass sie "general-purpose" sind und versuchen alle Eventualitäten abzudecken und damit auch Sachen, von denen ich weiss, dass wir sie sehr wahrscheinlich nicht in unseren Datenbanken haben werden (zum Beispiel LOB Spalten und/oder XML Indexes). Anfangs habe ich dann versucht, diese Spezialitäten aus den Skripten rauszunehmen, habe dann aber festgestellt, dass ich dafür länger brauche als was eigenes zu schreiben.

Ausserdem brauche ich das nur für 3 Datenbanken auf einem Server. Unsere Produktions-DBAs haben ihre eigenen Skripts, die sie auf allen ihren Servern laufen lassen.

Dein Ablauf klingt so wie unser war, bevor wir festgestellt haben, dass das Feststellen der Fragmentierung bei grösseren Tabellen richtig lange dauern kann. Abhängig von der Grösse Deiner Indexes würde ich das im Auge behalten, ob das mit dem Wartungsfenster so hinkommt oder wie uns, aus dem Ruder läuft. :-)]]></content:encoded>
			<link>https://www.insidesql.org/blogs/frankkalis/2011/02/02/index-maintenance-oder-dm_db_index_physical_stats-ist-langsam#c1156</link>
		</item>
		<item>
			<title>dirk in Antwort auf: Index Maintenance oder dm_db_index_physical_stats ist langsam</title>
			<pubDate>Thu, 17 Feb 2011 09:55:41 +0000</pubDate>
			<dc:creator><a href="https://www.insidesql.org/blogs/frankkalis/?disp=user&amp;user_ID=34" title="Benutzerprofil anzeigen" class="login user nowrap" rel="bubbletip_user_34"><span class="identity_link_username">dirk</span></a></dc:creator>
			<guid isPermaLink="false">c1155@https://www.insidesql.org/blogs/</guid>
			<description>Hallo Frank,

für die Index-Wartung verwende ich das Index Defag Script (&lt;a href=&quot;http://sqlfool.com/2010/04/index-defrag-script-v4-0/&quot;&gt;http://sqlfool.com/2010/04/index-defrag-script-v4-0/&lt;/a&gt;) von Michelle Ufford.
Dies ist für meine Zwecke mehr als praktikabel, da man mit Hilfe der zu übergebenden Parameter sehr gut steuern kann, wann welche Indizes angepackt werden sollen. Bisher hab ich aber nur Erfahrungen in Test-Systemen damit sammeln können, da für die produktiven Systeme noch die Wartungsfenster definiert werden müssen.
Ich verfolge aber auch einen hybriden Ansatz (das Script bietet die Option).
Beim ersten Lauf wird ermittelt, welche Indizes überhaupt gewartet werden müssen und in eine Tabelle festgehalten. Danach wird die Tabelle abgearbeitet. Dabei gebe ich der Prozedur noch eine Laufzeit von x Minuten mit. Über dieses Limit hinaus wird dann kein neuer Index mehr angepackt, bis es zum nächsten Aufruf kommt.
Dann wird erst die Tabelle weiter abgearbeitet, bis eine erneute Ermittlung der Fragemtierung erfolgt.

Gruß
Dirk</description>
			<content:encoded><![CDATA[Hallo Frank,

für die Index-Wartung verwende ich das Index Defag Script (<a href="http://sqlfool.com/2010/04/index-defrag-script-v4-0/">http://sqlfool.com/2010/04/index-defrag-script-v4-0/</a>) von Michelle Ufford.
Dies ist für meine Zwecke mehr als praktikabel, da man mit Hilfe der zu übergebenden Parameter sehr gut steuern kann, wann welche Indizes angepackt werden sollen. Bisher hab ich aber nur Erfahrungen in Test-Systemen damit sammeln können, da für die produktiven Systeme noch die Wartungsfenster definiert werden müssen.
Ich verfolge aber auch einen hybriden Ansatz (das Script bietet die Option).
Beim ersten Lauf wird ermittelt, welche Indizes überhaupt gewartet werden müssen und in eine Tabelle festgehalten. Danach wird die Tabelle abgearbeitet. Dabei gebe ich der Prozedur noch eine Laufzeit von x Minuten mit. Über dieses Limit hinaus wird dann kein neuer Index mehr angepackt, bis es zum nächsten Aufruf kommt.
Dann wird erst die Tabelle weiter abgearbeitet, bis eine erneute Ermittlung der Fragemtierung erfolgt.

Gruß
Dirk]]></content:encoded>
			<link>https://www.insidesql.org/blogs/frankkalis/2011/02/02/index-maintenance-oder-dm_db_index_physical_stats-ist-langsam#c1155</link>
		</item>
			</channel>
</rss>
