SQL Server 2012

Guten Tag zusammen,

ich spiele gerade ein wenig mit dem SQL Server 2012. Hier gibt es ein neues Feature namens "COLUMNSTORE INDEX". Dem ersten Lesen nach dachte ich das ist für NAV bestimmt interessant (z. B. für die Problematik mit http://www.msdynamics.de/viewtopic.php?f=40&t=16622) oder anderen evtl. direkt auf SQL laufenden Auswertungen. Hierbei bin ich aber auf ein von NAV verursachtes Problem gestoßen: Alle Felder vom SQL-Typ Decimal werden mit Decimal(38,20) angelegt.

1. Der Columnstoreindex kann nur bis Decimal(18,x)
2. Warum werden die Felder in dieser Größe angelegt? Wer braucht das?

ACHTUNG: Columnstore Index nicht einfach einsetzen! Tabellen mit aktivem Columnstore Index können keine weiteren Daten hinzugefügt werden. Nach deaktivierung des Index funktioniert das allerdings wieder.

Volker

NAV legt SQL Decimal mit 38,20 an?
Das könnte sich evtl. mit NAV 2013 ändern, da dort ja die Feldtypen auf SQL geändert haben. Vielleicht wurde decimal auch überarbeitet.

NAV legt SQL Decimal mit 38,20 an?
Das könnte sich evtl. mit NAV 2013 ändern, da dort ja die Feldtypen auf SQL geändert haben. Vielleicht wurde decimal auch überarbeitet.

Leider in NAV 2013 [bisher] keine Änderungen: Decimal 38,20

So, ich verheirate dasmal kurz mit http://social.msdn.microsoft.com/Forums/de-DE/sqlserverde/thread/59e1ee7b-9df6-4a4c-90ec-95ae6d072602/.

Was ich nicht verstehe ist der Grund für solche großen Felder. Wer braucht das in NAV? Was übersehe ich?

Volker

Ich wollte noch etwas SQL-Code nachschieben:

Code:

DECLARE @table table(Id int IDENTITY(1,1)
               , Name varchar(256))

INSERT INTO @table
SELECT b.name + '.'+ a.name
FROM sys.tables a INNER JOIN sys.schemas b
      ON a.schema_id = b.schema_id

INSERT INTO @table
SELECT '-1'

DECLARE @result table(   TableName varchar(256)
                  , TotalRows int
                  , Reserved varchar(50)
                  , DataSize varchar(50)
                  , IndexSize varchar(50)
                  , UnusedSize varchar(50))

DECLARE @temp varchar(256)
DECLARE @index int
SET @index = 1

WHILE 1=1
BEGIN
   SELECT @temp = Name
   FROM @table
   WHERE Id = @index

   IF @temp = '-1'
      BREAK   

   INSERT @result(   TableName
               , TotalRows
               , Reserved
               , DataSize
               , IndexSize
               , UnusedSize)
   EXEC sp_spaceused @temp

   SET @index = @index + 1
END

SELECT c.name+'.'+b.name as [table]
      , a.*
 FROM @result a
      INNER JOIN sys.tables b
         ON a.TableName = b.name
      INNER JOIN sys.schemas c
      ON b.schema_id = c.schema_id
ORDER BY TotalRows DESC
 


Interessant finde ich dabei (zumindest bei uns) wieviel Platz in der DB resierviert ist und wieviel tatsächlich genutzt wird. Ich habe bei uns häufig Werte von gerade mal 50% des reservierten Speichers. Undich habe mich schon die ganze Zeit gewundert, warum man die normal NAV-Sicherung mit Winrar um den Faktor 15 verkleinern konnte. Kein Wunder wenn die Felder zu 50% leer sind.

Volker

So, ich verheirate dasmal kurz mit http://social.msdn.microsoft.com/Forums/de-DE/sqlserverde/thread/59e1ee7b-9df6-4a4c-90ec-95ae6d072602/.

Was ich nicht verstehe ist der Grund für solche großen Felder. Wer braucht das in NAV? Was übersehe ich?

Volker

Ich würde vermuten das liegt an der internen Darstellung im Navision bzw. am BCD Code der Dezimalzahl.
Da Navision intern 18 Stellen für Dezimalzahlen verwendet muss das Feld im SQL Server das auch berücksichtigen.
Die interne Darstellung (ohne Vorzeichen) könnte von 0,123456789012345678 zu 123456789012345,678 variieren.
Demnach müsste der SQL Server vom schlimmsten Fall ausgehen und 18 Nachkommastellen oder aber 15 Vorkommastellen berücksichtigen. Da kam DECIMAL(38,20) dem wohl am nächsten?

A decimal number between -10^63 and 10^63. The exponent ranges from -63 to 63. Decimal numbers are held in memory with 18 significant digits. The representation of a decimal number is a Binary Coded Decimal (BCD). The size of the corresponding SQL data type,

DECIMAL(38,20), is 17 bytes. (A)(B)

(Link)

mfg,
winfy

...Da Navision intern 18 Stellen für Dezimalzahlen verwendet muss das Feld im SQL Server das auch berücksichtigen.
...

Und da war die fehlende Info.

Blöd, dass damit die Möglichkeiten eines SQL 2012 nicht ausgenutzt werden können. Aber wer braucht 18 Nachkommastellen? Kann da einer einen Fall in NAV nennen, bei dem das notwendig ist?

Volker

Blöd, dass damit die Möglichkeiten eines SQL 2012 nicht ausgenutzt werden können. Aber wer braucht 18 Nachkommastellen? Kann da einer einen Fall in NAV nennen, bei dem das notwendig ist?

Volker

Ich würde dir ansich schon Recht geben.
Es war allerdings diesen Monat ein Beitrag, da hat das wohl einer für die Umrechnung der Artikeleinheiten benötigt (Link).

Eine fest definierte Anzahl an Nachkommastellen bringt unter Umständen auch Probleme mit sich - vorallem bei darauf resultierenden internen Rechenoperationen.
Dieser SQL-Artikel und die darin enthaltenen Artikel und Kommentare, fand ich in dem Zusammenhang auch sehr aufschlussreich (Link).

mfg,
winfy