Frank Kalis

USE pubs
GO
SELECT 
	DATEDIFF(DAY, pubdate, GETDATE()) AS Anzahl_Tage
FROM 
	titles
GO 

Anzahl_Tage 
----------- 
4761
4764
4743
4751
4764
4755
1418
4743
3665
1418
4630
4758
4646
4761
4761
4630
4761
4761

(18 row(s) affected)

Im Bezug auf das Transaktionsprotokoll des SQL Servers scheint es eine ziemliche Unsicherheit bei den meisten Anwendern zu geben. Dabei ist dies bei weitem kein Mysterium!

Ganze Geschichte »

USE MASTER
GO
SELECT
	CASE OBJECTPROPERTY(id, 'IsMSShipped')
		WHEN 1 THEN 'Bei Installation erzeugt'
		WHEN 0 THEN 'Nicht bei Installation erzeugt'
	END AS [Bei Installation Erzeugt]
	, CAST(name AS CHAR(30)) AS [name]
FROM
	sysobjects 
WHERE
	name = 'sp_helpdb'
OR
	name = 'sp_MBL_SORT'

Bei Installation Erzeugt       name                           
------------------------------ ------------------------------ 
Bei Installation erzeugt       sp_helpdb                     
Nicht bei Installation erzeugt sp_MBL_SORT                   

(2 row(s) affected)

SELECT
 OBJECT_NAME(Id) as [Table]
 , name as [Column]
 , TYPE_NAME(xusertype) as Type
  FROM SysColumns 
 WHERE TYPE_NAME(xusertype) 
  IN ('varchar','char') 
  AND ID IN 
  (SELECT ID
     FROM SysObjects 
    WHERE xtype = 'U') 
 ORDER BY OBJECT_NAME(Id), Name

Die Ergebnismenge wird hier nicht wiedergegeben, da sie in der Regel sehr umfangreich ist. Ändert man

 WHERE xtype = 'U') 

in

 WHERE xtype = 'P') 

erhält man das Ergebnis für Gespeicherte Prozeduren.

SELECT
	DATEPART(yy , GETDATE()) AS Jahr
 	, DATEPART(qq , GETDATE()) AS Quartal
 	, DATEPART(mm , GETDATE()) AS Monat
	, DATEPART(dd , GETDATE()) AS Tag
	, DATEPART(hh , GETDATE()) AS Stunden
	, DATEPART(mi , GETDATE()) AS Minuten
	, DATEPART(ss , GETDATE()) AS Sekunden
	, DATEPART(ms , GETDATE()) AS Millisekunden
	, DATEPART(wk , GETDATE()) AS Woche


Jahr      Quartal   Monat     Tag       Stunden   Minuten   Sekunden  Millisekunden Woche
--------- --------- --------- --------- --------- --------- --------- ------------- -----
2004      2         6         23        11        23        59        513           26

(1 row(s) affected)

Weitere Informationen stehen in BOL.

Generell gilt, daß Indexes Datenabfragen enorm beschleunigen können. Nachteil aber ist, daß Änderungen an den Daten sich auch in Änderungen in den Indexes manifestieren, falls die entsprechenden Spalten, die von der Änderung betroffen sind, auch gleichzeitig Teil eines oder mehrerer Indexes sind. Indexes aber sind kein starres Konzept, von dem man nicht abweichen darf. So macht es zum Beispiel durchaus Sinn, vor dem Auffüllen einer Tabelle durch einen Massenimport, vorhandene Indexes auf der Tabelle zu löschen, um den Import zu beschleunigen und vielleicht innerhalb eines vorgegebenen Zeitfensters beenden zu können. Die Frage, ob in einem solchen Fall nicht besser die gesamte Tabelle gelöscht und neu erstellt wird, ignorieren wir an dieser Stelle. Sie ist ein eigenes Thema und nicht Gegenstand dieser Betrachtung.

Ganze Geschichte »

Direktes Updaten der Systemtabellen ist eine der schnellsten Methoden, um SQL Server in die Irre zu führen. Daher sollte dies nur im Notfall angewendet werden:

Ganze Geschichte »

In SQL 6.5 gibt es eine Einstellungen 'tempdb in RAM'. Ab Version 7 wird dies nicht mehr unterstützt. Microsoft ist der Ansicht, daß die internen Zugriffe genügend optimiert sind, um dies unnötig zu machen