2013-08-01 17 views
9

In SQL Azure fehlen, habe ich eine Tabelle mehr oder weniger wie diese aufgebaut, mit zwei berechneten Spalten (IsExpired und IsDeadlineExpired), die einfach vergleichen Nicht-Nullable-Datetime-Spalten auf die aktuelle Zeit:Berechnete Spalten von SELECT *

CREATE TABLE [dbo].[Stuff] 
(
    [StuffId] int NOT NULL IDENTITY(1,1), 
    [Guid] uniqueidentifier NOT NULL, 
    [ExpirationDate] datetime NOT NULL, 
    [DeadlineDate] datetime NOT NULL, 
    [UserId] int NOT NULL, 
    [IsExpired] AS CAST((CASE WHEN [ExpirationDate] < GETUTCDATE() THEN 1 ELSE 0 END) AS bit), 
    [IsDeadlineExpired] AS CAST((CASE WHEN [DeadlineDate] < GETUTCDATE() THEN 1 ELSE 0 END) AS bit), 
    CONSTRAINT [PK_StuffId] PRIMARY KEY ([StuffId]), 
    CONSTRAINT [UNQ_Guid] UNIQUE([Guid]), 
) 
GO 

ich habe eine gespeicherte Prozedur mit mehreren Ergebnismengen, von denen ziehen:

SELECT * FROM [dbo].[Stuff] WHERE [Guid] = @guid 

ich habe anzeigt Fehlerprotokolle vor kurzem festgestellt, dass manchmal, wenn die Ergebnismenge mit SqlDataReader gelesen wird, SqlDataReader.GetOrdinal("IsExpired") schlägt mit IndexOutOfRangeException fehl. Ich weiß, dass die vorhergehenden Spalten auch in diesen Fällen gut funktionieren, da sie in den vorhergehenden Codezeilen ohne Fehler gelesen werden. Ich glaube auch, dass die Ergebnismengen von der Prozedur in der richtigen Reihenfolge sind, da sie keine Spaltennamen teilen (andernfalls würde das Lesen der früheren Spalten ähnlich fehlschlagen).

Auch: die meiste Zeit scheint alles perfekt zu funktionieren.

Kann dies irgendwie auf vorübergehende Azure-Fehler zurückzuführen sein?

+3

Und noch ein weiterer Grund, der meine Wahl unterstützt, '' '' '' –

+0

nicht zu verwenden, würde es, um explizite Spalten zu bearbeiten, vorzuziehen sein und würde es wahrscheinlich 100% funktionieren lassen, aber ich hätte nie erwartet, dass sich '*' so verhält. Ich habe es hauptsächlich gepostet, weil es so ein Nudelscratcher ist. –

+0

Ja, es ist ziemlich merkwürdig. Wurden diese Spalten später hinzugefügt? –

Antwort

0

Wenn wir uns einige alte Protokolle ansehen, haben wir festgestellt, dass dieser Fehler nur auftritt, wenn die Abfragen während der Bereitstellung eines DACPAC gleichzeitig ausgeführt wurden (als Teil unserer automatisierten Bereitstellungen für diese spezielle Testumgebung).

Ich nehme an, dass das Schema während der DACPAC-Bereitstellung nicht unbedingt in einem zuverlässigen Zustand ist.

Seitdem haben wir einen Code hinzugefügt, um die App während der Bereitstellung in einen "Wartungsmodus" zu versetzen (selbst diese automatisierten). Dies scheint das Problem zu mildern.

1

Bitte beachten Sie diesen Artikel: SELECT * AND SQL Azure.

Sein Autor stark

SELECT * 
FROM TableName 

mit

SELECT [Column1], [Column2], ... [ColumnN] 
FROM TableName 

weil SELECT * Bei Verwendung verursachen kann zusätzlichen Paging, RFID-Lookups, nicht benötigte Tabellensperren zu ersetzen empfehlen und behindert alle zukünftigen Versuche, eine zu schaffen gedeckter Index. Zusammenfassend ist es schlecht für die Leistung.

By The Way: hier haben Sie eine Reihe von interessanten Artikeln bekommen:

  1. How to get to SQL Azure Query Performance Data
  2. Query Performance
  3. Getting Started with the Windows Azure Tools for Visual Studio
  4. Getting Started with SQL Azure Development
  5. Improving Your I/O Performance
  6. Analyzing Query Performance just got easier with SQL Azure.

Ich vermute, dass GetOrdinary ("isExpired")System.IndexOutOfRangeException von MS SQL Azure Framework wegen obigen Verhaltens verursacht.

Fazit? Verwenden Sie SELECT Anweisung mit definierten Liste der Spalten, um die Leistung der SQL Azure-Datenbank zu verbessern und IndexOutOfRange Ausnahme zu vermeiden.

Verwandte Themen