2016-04-20 6 views
19

Fino a pochi giorni fa sono riuscito a importare un BACPAC V12 da Azure al mio server locale con SQL Server 2014 SP1 CU6 (12.0.4449.0).Errore di importazione SQL Azure V12 BACPAC: "Il tipo di piattaforma di destinazione interna SqlAzureV12DatabaseSchemaProvider non supporta la versione del file di schema '3.3'"

Ma ora, quando cerco di importare il BacPac, il mio SQL Server Management Studio 2014 dice:.

"Errore interno Il tipo di piattaforma di destinazione SqlAzureV12DatabaseSchemaProvider interna non supporta la versione file di schema '3.3' (file.: D: \ MyDB.bacpac) (Microsoft.Data.Tools.Schema.Sql) "

Penso di avere la versione più recente di SQL Server 2014 SP1 con tutti gli aggiornamenti più recenti (build 12.0.4449.0) ma continuo a ricevere questo errore

Si prega di aiuto!

Grazie

+0

Siamo spiacenti, ho po 'di confusione. Ho ragione che intendi che sei riuscito ad importare BACPAC un giorno e non è stato possibile importare BACPAC con la stessa versione di SSMS un altro giorno? Sei sicuro che non ci siano stati aggiornamenti? –

+0

Esattamente! Sono stato in grado di importare il seguente file: MyDB-2016-4-18-21-51.bacpac e due giorni dopo MyDB-2016-4-20-10-18.bacpac mi ha dato l'errore! E non c'erano aggiornamenti. Due giorni :) – Stefano

risposta

20

Fix: Per risolvere, utilizzare il latest SSMS Preview che installa la più aggiornata versione DacFx. Questo capisce come elaborare le funzionalità più recenti, in particolare le opzioni di configurazione di Database Scoped. Una volta installato, puoi importare all'interno di SSMS o usare SqlPackage dal percorso "C: \ Programmi (x86) \ Microsoft SQL Server \ 130 \ DAC \ bin" se preferisci gli strumenti da riga di comando.

In alternativa, eseguire il comando seguente nel database di Azure per impostare il valore di MaxDop sul valore predefinito poiché sembra che il problema sia stato modificato in 1. Le esportazioni future dovrebbero ora produrre bacpac comprensibili dagli strumenti client 2014 , supponendo che nessun'altra nuova funzionalità di Azure sia stata aggiunta al DB.

ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 0 

Causa principale/perché questo accade: La causa principale è che il database ha valori non predefiniti per 1 o più database Scoped opzioni di configurazione. Poiché questi sono stati aggiunti solo molto recentemente, le versioni precedenti degli strumenti non capiscono come distribuirle e quindi i blocchi DacFx. Queste sono le sole proprietà/oggetti con una versione di schema così alta. Fondamentalmente ogni volta che vedi un errore del tipo "non supporta la versione del file di schema '3.3'" significa che devi aggiornare. Una causa possibile è se il database è stato migrato da AzureV1 -> AzureV12, che imposta l'opzione MAXDOP a 1 dal suo default, 0.

Note: Si raccomanda vivamente di utilizzare i più recenti SSMS e tenerlo fino a data tramite le notifiche di aggiornamento integrate se stai lavorando con Azure. ti assicurerà di evitare di incorrere in problemi come questo. In genere, se si utilizza solo l'area di superficie di SQL Server 2014, è possibile utilizzare strumenti precedenti durante la reimportazione, ma con l'enorme numero di miglioramenti recenti nei casi di SQL SQL di Azure, come in questo caso, verranno visualizzati sempre più spesso i nuovi strumenti sono necessari per eseguire come previsto.

Per riferimento, sono incluse le opzioni di configurazione del database con i relativi valori predefiniti di seguito. Se una di queste proprietà è non predefinita sul DB quando si esporta la versione dello schema viene eseguito il bump in modo che i vecchi strumenti non si interrompano.

<!-- Database Scoped Configurations--> 
<Property Name="MaxDop" Type="System.Int32" DefaultValue="0" /> 
<Property Name="MaxDopForSecondary" Type="System.Int32?" DefaultValue="null"/> 
<Property Name="LegacyCardinalityEstimation" Type="System.Boolean" DefaultValue="false" /> 
<Property Name="LegacyCardinalityEstimationForSecondary" Type="System.Boolean?" DefaultValue="null" /> 
<Property Name="ParameterSniffing" Type="System.Boolean" DefaultValue="true" /> 
<Property Name="ParameterSniffingForSecondary" Type="System.Boolean?" DefaultValue="null" /> 
<Property Name="QueryOptimizerHotfixes" Type="System.Boolean" DefaultValue="false" /> 
<Property Name="QueryOptimizerHotfixesForSecondary" Type="System.Boolean?" DefaultValue="null" /> 
+0

Funziona, grazie! – Stefano

+0

Grazie, ma perché le opzioni di configurazione del database vengono modificate da un giorno all'altro? Ho lo stesso problema in un sito client in cui i backup fino al 18 aprile vanno bene, ma dal 19 aprile hanno iniziato a fallire. Non abbiamo apportato modifiche allo schema in quel momento. – yowl00

+0

@ yowl00: questa è una buona domanda. Sto seguendo il team del prodotto principale che ha aggiunto questo per vedere se qualcosa sta cambiando automaticamente le impostazioni. Per riferimento, il problema per un altro cliente sembra essere che MAXDOP è impostato su 1 (il valore predefinito è 0). L'unico modo in cui ciò dovrebbe accadere ora è se il DB viene aggiornato da V11 -> V12 poiché questo era il valore del flag in quella versione. Aggiungerò una soluzione alla risposta nel caso in cui non si voglia aggiornare gli strumenti client. –

2

La soluzione più semplice "Alter" dato da Kevin (ALTER DATABASE con ambito CONFIGURAZIONE SET MAXDOP = 0) sembra essere la soluzione veloce per risolvere la crisi per chiunque abbia problemi dei clienti-down. Non importa di installare l'ultimo DAC o SQL Server 2016, non è necessario risolvere il problema immediato, PLUS tutto ciò che è in stato di anteprima (beta).Difficilmente qualcosa che si vuole introdurre in un ambiente di produzione in questo momento

Questo a quanto pare è successo solo a noi se avessimo un database v11 in attesa di aggiornamento automatico da MSFT impostato per questo ultimo fine settimana. Per quegli aggiornamenti del database abbiamo annullato e applicato noi stessi l'aggiornamento, il campo Max Degree Of Parallelism non è stato impostato su 0 e si è verificato questo errore. Abbiamo circa 300 db e ho notato questo come il modello

FYI: è possibile verificare la presenza di quel valore problema con questa query SQL

SELECT [dbscm].[value]       AS [MaxDop], 
    [dbscm].[value_for_secondary]   AS [MaxDopForSecondary], 
    [dbscl].[value]       AS [LegacyCardinalityEstimation], 
    [dbscl].[value_for_secondary]   AS  
    [LegacyCardinalityEstimationForSecondary], 
    [dbscp].[value]       AS [ParameterSniffing], 
    [dbscp].[value_for_secondary]   AS 
    [ParameterSniffingForSecondary], 
    [dbscq].[value]       AS [QueryOptimizerHotfixes], 
    [dbscq].[value_for_secondary]   AS 
    [QueryOptimizerHotfixesForSecondary] 
    FROM [sys].[databases] [db] WITH (NOLOCK) 
    LEFT JOIN [sys].[database_scoped_configurations] AS [dbscm] WITH 
    (NOLOCK) ON [dbscm].[name] = N'MAXDOP' 
    LEFT JOIN [sys].[database_scoped_configurations] AS [dbscl] WITH 
    (NOLOCK) ON [dbscl].[name] = N'LEGACY_CARDINALITY_ESTIMATION' 
    LEFT JOIN [sys].[database_scoped_configurations] AS [dbscp] WITH 
    (NOLOCK) ON [dbscp].[name] = N'PARAMETER_SNIFFING' 
    LEFT JOIN [sys].[database_scoped_configurations] AS [dbscq] WITH 
    (NOLOCK) ON [dbscq].[name] = N'QUERY_OPTIMIZER_HOTFIXES' 
    WHERE [db].[name] = DB_NAME(); 
0

stavo affrontando lo stesso problema mentre ero l'importazione di un export da azzurro a la mia istanza locale MSSQLLocalDB (per il debug locale).

Non volevo toccare il db azzurro né volevo scaricare l'ultima anteprima.

Quindi quello che ho fatto è stato come segue Sulla mia db locale:

  1. eseguita l'impostazione del valore per MAXDOP interrogazione alter al 1
    ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 1

  2. importato il BacPac, che si è svolta con successo.

  3. Resto del valore di MAXDOP al 0
    ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 0

Speranza che aiuta qualcuno simile caso d'uso

Problemi correlati