Flytta data mellan utskalade molndatabaser

Gäller för:Azure SQL Database

Om du är utvecklare av programvara som en tjänst, och plötsligt din app genomgår en enorm efterfrågan, måste du hantera tillväxten. Så du lägger till fler databaser (shards). Hur omdistribuerar du data till de nya databaserna utan att störa dataintegriteten? Använd verktyget för delningssammanslagning för att flytta data från begränsade databaser till de nya databaserna.

Verktyget för delningskoppling körs som en Azure-webbtjänst. En administratör eller utvecklare använder verktyget för att flytta shardletar (data från en shard) mellan olika databaser (shards). Verktyget använder hantering av fragmentkartor för att underhålla tjänstens metadatadatabas och säkerställa konsekventa mappningar.

Ladda ned

Microsoft.Azure.SqlDatabase.ElasticScale.Service.SplitMerge

Dokumentation

1. Självstudie om verktyg för delad sammanslagning av elastisk databas
2. Säkerhetskonfiguration för delad sammanslagning
3. Säkerhetsöverväganden för delad sammanslagning
4. Karthantering för shard
5. Migrera befintliga databaser till utskalning
6. Elastiska databasverktyg
7. Ordlista för verktyg i elastiska databaser

Varför använda verktyget för delningssammanslagning

• Flexibilitet

  Program måste sträcka sig flexibelt utanför gränserna för en enskild databas i Azure SQL Database. Använd verktyget för att flytta data efter behov till nya databaser samtidigt som integriteten bevaras.

• Dela för att växa

  Om du vill öka den totala kapaciteten för att hantera explosiv tillväxt skapar du ytterligare kapacitet genom att partitionera data och distribuera dem över inkrementellt fler databaser tills kapacitetsbehoven uppfylls. Det här är ett utmärkt exempel på delningsfunktionen.

• Sammanfoga för att krympa

  Kapacitetsbehoven minskar på grund av ett företags säsongsmässiga karaktär. Med verktyget kan du skala ned till färre skalningsenheter när verksamheten saktar ner. Sammanslagningsfunktionen i tjänsten Elastic Scale Split-Merge täcker detta krav.

• Hantera hotspots genom att flytta shardletar

  Med flera klienter per databas kan allokeringen av shardletar till shards leda till kapacitetsflaskhalsar på vissa shards. Detta kräver omallokering av shardletar eller flytt av upptagna shardletar till nya eller mindre använda shards.

Begrepp och viktiga funktioner

• Kundvärdstjänster

  Delningskopplingen levereras som en kundhanterad tjänst. Du måste distribuera och vara värd för tjänsten i din Microsoft Azure-prenumeration. Paketet som du laddar ned från NuGet innehåller en konfigurationsmall för att slutföra med informationen för din specifika distribution. Mer information finns i självstudien om delningssammanslagning. Eftersom tjänsten körs i din Azure-prenumeration kan du styra och konfigurera de flesta säkerhetsaspekter av tjänsten. Standardmallen innehåller alternativ för att konfigurera TLS, certifikatbaserad klientautentisering, kryptering för lagrade autentiseringsuppgifter, DoS-skydd och IP-begränsningar. Du hittar mer information om säkerhetsaspekterna i följande dokument för säkerhetskonfiguration med delad sammanslagning.

  Den distribuerade standardtjänsten körs med en arbets- och en webbroll. Var och en använder storleken på den virtuella A1-datorn i Azure Cloud Services. Du kan inte ändra de här inställningarna när du distribuerar paketet, men du kan ändra dem efter en lyckad distribution i den molntjänst som körs (via Azure-portalen). Observera att arbetsrollen inte får konfigureras av mer än en enskild instans av tekniska skäl.

• Integrering av fragmentkarta

  Split-merge-tjänsten interagerar med shardkartan för programmet. När du använder split-merge-tjänsten för att dela eller slå samman intervall eller för att flytta shardlets mellan shards, håller tjänsten automatiskt fragmentkartan uppdaterad. För att göra det ansluter tjänsten till programmets shard map manager-databas och underhåller intervall och mappningar när begäranden delas/sammanfogas/flyttas. Detta säkerställer att shardkartan alltid visar en uppdaterad vy när åtgärder för delningssammanslagning pågår. Åtgärder för att dela, sammanfoga och shardletar implementeras genom att flytta en batch med shardletar från källshard till målshard. Under shardlet-förflyttningsåtgärden markeras de shardlets som omfattas av den aktuella batchen som offline på shardkartan och är inte tillgängliga för databeroende routningsanslutningar med hjälp av API:et Open Anslut ionForKey.

• Konsekventa shardlet-anslutningar

  När dataflytten startar för en ny batch med shardletar, blockeras eventuella databeroende routningsanslutningar till shardleten som lagrar shardleten och efterföljande anslutningar från Shard Map-API:erna till shardletarna blockeras medan dataförflyttningen pågår för att undvika inkonsekvenser. Anslut joner till andra shardletar på samma fragment kommer också att avlivas, men kommer att lyckas igen omedelbart vid återförsök. När batchen har flyttats markeras shardletarna online igen för målsharden och källdata tas bort från källshard. Tjänsten går igenom de här stegen för varje batch tills alla shardletar har flyttats. Detta leder till flera åtgärder för att avbryta anslutningen under den fullständiga åtgärden split/merge/move.

• Hantera shardlet-tillgänglighet

  Om anslutningsavlivningen begränsas till den aktuella batchen med shardletar enligt beskrivningen ovan begränsas omfattningen av otillgängligheten till en batch med shardletar i taget. Detta rekommenderas framför en metod där den fullständiga fragmentet skulle förbli offline för alla dess shardletar under en delnings- eller sammanslagningsåtgärd. Storleken på en batch, definierad som antalet distinkta shardletar som ska flyttas åt gången, är en konfigurationsparameter. Det kan definieras för varje delnings- och sammanslagningsåtgärd beroende på programmets tillgänglighets- och prestandabehov. Observera att intervallet som är låst i fragmentkartan kan vara större än den angivna batchstorleken. Det beror på att tjänsten väljer intervallstorleken så att det faktiska antalet partitioneringsnyckelvärden i data ungefär matchar batchstorleken. Detta är viktigt att komma ihåg särskilt för glesbefolkade fragmenteringsnycklar.

• Metadatalagring

  Tjänsten för delningssammanslagning använder en databas för att behålla dess status och för att behålla loggar under bearbetningen av begäranden. Användaren skapar den här databasen i sin prenumeration och tillhandahåller anslutningssträng för den i konfigurationsfilen för tjänstdistributionen. Administratörer från användarens organisation kan också ansluta till den här databasen för att granska förloppet för begäran och undersöka detaljerad information om potentiella fel.

• Sharding-awareness

  Split-merge-tjänsten skiljer mellan (1) shardade tabeller, (2) referenstabeller och (3) normala tabeller. Semantiken för en split/merge/move-åtgärd beror på vilken typ av tabell som används och definieras på följande sätt:

  • Shardade tabeller

    Dela, sammanfoga och flytta åtgärder flyttar shardletar från källa till målshard. När den övergripande begäran har slutförts finns inte längre dessa shardletar på källan. Observera att måltabellerna måste finnas på målshard och inte får innehålla data i målintervallet innan åtgärden bearbetas.

  • Referenstabeller

    För referenstabeller kopierar åtgärderna split, merge och move data från källan till målshard. Observera dock att inga ändringar sker på målshard för en viss tabell om någon rad redan finns i den här tabellen på målet. Tabellen måste vara tom för att en referenstabellkopia ska kunna bearbetas.

  • Andra tabeller

    Andra tabeller kan finnas på antingen källan eller målet för en delnings- och sammanslagningsåtgärd. Split-merge-tjänsten bortser från dessa tabeller för dataflytt eller kopieringsåtgärder. Observera dock att de kan störa dessa åtgärder i händelse av begränsningar.

    Informationen om referens eller shardade tabeller tillhandahålls av API:erna SchemaInfo på fragmentkartan. I följande exempel visas hur dessa API:er används på ett visst objekt för shard map manager:

    // Create the schema annotations
    SchemaInfo schemaInfo = new SchemaInfo();
    
    // reference tables
    schemaInfo.Add(new ReferenceTableInfo("dbo", "region"));
    schemaInfo.Add(new ReferenceTableInfo("dbo", "nation"));
    
    // sharded tables
    schemaInfo.Add(new ShardedTableInfo("dbo", "customer", "C_CUSTKEY"));
    schemaInfo.Add(new ShardedTableInfo("dbo", "orders", "O_CUSTKEY"));
    
    // publish
    smm.GetSchemaInfoCollection().Add(Configuration.ShardMapName, schemaInfo);
    

    Tabellerna region och nation definieras som referenstabeller och kopieras med split/merge/move-åtgärder. customer och orders definieras i sin tur som shardade tabeller. C_CUSTKEY och O_CUSTKEY fungerar som horisontell partitioneringsnyckel.

• Referensintegritet

  Tjänsten för delningssammanslagning analyserar beroenden mellan tabeller och använder sekundärnyckel-primära nyckelrelationer för att mellanlagra åtgärderna för att flytta referenstabeller och shardletar. I allmänhet kopieras referenstabeller först i beroendeordning och sedan kopieras shardletar i ordning efter deras beroenden i varje batch. Detta är nödvändigt så att FK-PK-begränsningar på målshard respekteras när nya data tas emot.

• Shard map-konsekvens och slutlig slutförande

  I händelse av fel återupptar split-merge-tjänsten åtgärder efter eventuella avbrott och syftar till att slutföra pågående begäranden. Det kan dock finnas oåterkalleliga situationer, t.ex. när målskärvan går förlorad eller komprometteras bortom reparation. Under dessa omständigheter kan vissa shardletar som skulle flyttas fortsätta att finnas på källshard. Tjänsten ser till att shardlet-mappningar endast uppdateras efter att nödvändiga data har kopierats till målet. Shardlets tas bara bort på källan när alla deras data har kopierats till målet och motsvarande mappningar har uppdaterats. Borttagningsåtgärden sker i bakgrunden medan intervallet redan är online på målshard. Tjänsten för delningssammanslagning säkerställer alltid att mappningarna som lagras på fragmentkartan är korrekta.

Användargränssnittet för delad sammanslagning

Tjänstpaketet för delad sammanslagning innehåller en arbetsroll och en webbroll. Webbrollen används för att skicka begäranden om delad sammanslagning på ett interaktivt sätt. Huvudkomponenterna i användargränssnittet är följande:

• Åtgärdstyp

  Åtgärdstypen är en alternativknapp som styr vilken typ av åtgärd som utförs av tjänsten för den här begäran. Du kan välja mellan scenarierna split, merge och move. Du kan också avbryta en tidigare skickad åtgärd. Du kan använda delade, sammanfoga och flytta begäranden för intervallshardkartor. List-shardkartor stöder endast flyttåtgärder.

• Shard-karta

  Nästa avsnitt i begäransparametrarna innehåller information om shardkartan och databasen som är värd för fragmentkartan. I synnerhet måste du ange namnet på servern och databasen som är värd för shardkartan, autentiseringsuppgifter för att ansluta till shardmappningsdatabasen och slutligen namnet på fragmentkartan. För närvarande accepterar åtgärden endast en enda uppsättning autentiseringsuppgifter. Dessa autentiseringsuppgifter måste ha tillräcklig behörighet för att utföra ändringar i fragmentkartan samt användardata på fragmenten.

• Källintervall (dela och sammanfoga)

  En delnings- och sammanslagningsåtgärd bearbetar ett intervall med låg och hög nyckel. Om du vill ange en åtgärd med ett obundet högt nyckelvärde markerar du kryssrutan "Hög nyckel är max" och lämnar högnyckelfältet tomt. De intervallnyckelvärden som du anger behöver inte exakt matcha en mappning och dess gränser i fragmentkartan. Om du inte anger några intervallgränser alls kommer tjänsten att härleda det närmaste intervallet åt dig automatiskt. Du kan använda PowerShell-skriptet GetMappings.ps1 för att hämta de aktuella mappningarna i en viss shardkarta.

• Beteende för delad källa (delning)

  För delade åtgärder definierar du den punkt där källintervallet ska delas. Det gör du genom att ange partitioneringsnyckeln där du vill att delningen ska ske. Använd alternativknappen och ange om du vill att den nedre delen av intervallet (exklusive delningsnyckeln) ska flyttas eller om du vill att den övre delen ska flyttas (inklusive delningsnyckeln).

• Käll-shardlet (flytta)

  Flyttåtgärder skiljer sig från delnings- eller sammanslagningsåtgärder eftersom de inte kräver något intervall för att beskriva källan. En källa för flytt identifieras helt enkelt av värdet för partitioneringsnyckeln som du planerar att flytta.

• Målshard (delning)

  När du har angett informationen om källan för delningsåtgärden måste du definiera var du vill att data ska kopieras genom att ange server- och databasnamnet för målet.

• Målintervall (sammanslagning)

  Sammanslagningsåtgärder flyttar shardletar till en befintlig shard. Du identifierar den befintliga fragmentet genom att ange intervallgränserna för det befintliga intervall som du vill sammanfoga med.

• Batchstorlek

  Batchstorleken styr antalet shardletar som ska kopplas från vid en tidpunkt under dataflytten. Det här är ett heltalsvärde där du kan använda mindre värden när du är känslig för långa perioder av stilleståndstid för shardletar. Större värden ökar tiden då en viss shardlet är offline men kan förbättra prestandan.

• Åtgärds-ID (avbryt)

  Om du har en pågående åtgärd som inte längre behövs kan du avbryta åtgärden genom att ange dess åtgärds-ID i det här fältet. Du kan hämta åtgärds-ID:t från statustabellen för begäran (se avsnitt 8.1) eller från utdata i webbläsaren där du skickade begäran.

Krav och begränsningar

Den aktuella implementeringen av split-merge-tjänsten omfattas av följande krav och begränsningar:

• Fragmenten måste finnas och registreras i fragmentkartan innan en delningskopplingsåtgärd på dessa shards kan utföras.
• Tjänsten skapar inte tabeller eller andra databasobjekt automatiskt som en del av dess åtgärder. Det innebär att schemat för alla shardade tabeller och referenstabeller måste finnas på målshard före en delnings-/sammanslagnings-/flyttåtgärd. Särskilt fragmenterade tabeller måste vara tomma i intervallet där nya shardletar ska läggas till genom en delnings-/sammanslagnings-/flyttåtgärd. Annars misslyckas åtgärden med den inledande konsekvenskontrollen på målshard. Observera också att referensdata endast kopieras om referenstabellen är tom och att det inte finns några konsekvensgarantier för andra samtidiga skrivåtgärder i referenstabellerna. Vi rekommenderar detta: när du kör split/merge-åtgärder gör inga andra skrivåtgärder ändringar i referenstabellerna.
• Tjänsten förlitar sig på radidentitet som upprättats av ett unikt index eller en nyckel som innehåller partitioneringsnyckeln för att förbättra prestanda och tillförlitlighet för stora shardletar. På så sätt kan tjänsten flytta data med en ännu finare kornighet än bara värdet för partitioneringsnyckeln. Detta bidrar till att minska den maximala mängden loggutrymme och lås som krävs under åtgärden. Överväg att skapa ett unikt index eller en primärnyckel, inklusive partitioneringsnyckeln i en viss tabell om du vill använda tabellen med begäranden om att dela/sammanfoga/flytta. Av prestandaskäl bör partitioneringsnyckeln vara den inledande kolumnen i nyckeln eller indexet.
• Under bearbetningen av begäranden kan vissa shardlet-data finnas både på källan och målshard. Detta är nödvändigt för att skydda mot fel under shardlet-rörelsen. Integreringen av split-merge med shardkartan säkerställer att anslutningar via de databeroende routnings-API:erna med hjälp av metoden Open Anslut ionForKey på fragmentkartan inte ser några inkonsekventa mellanliggande tillstånd. Men när du ansluter till källan eller målshards utan att använda metoden Open Anslut ionForKey kan inkonsekventa mellanliggande tillstånd visas när begäranden om delning/sammanslagning/flytt pågår. Dessa anslutningar kan visa partiella eller duplicerade resultat beroende på tidpunkten eller shard som ligger bakom anslutningen. Den här begränsningen omfattar för närvarande anslutningar som görs av Elastic Scale Multi-Shard-Queries.
• Metadatadatabasen för split-merge-tjänsten får inte delas mellan olika roller. En roll för split-merge-tjänsten som körs i mellanlagringen måste till exempel peka på en annan metadatadatabas än produktionsrollen.

Fakturering

Split-merge-tjänsten körs som en molntjänst i din Microsoft Azure-prenumeration. Därför tillkommer avgifter för molntjänster för din instans av tjänsten. Såvida du inte ofta utför åtgärder för att dela/slå samman/flytta rekommenderar vi att du tar bort din molntjänst för delad sammanslagning. Det sparar kostnader för att köra eller distribuera molntjänstinstanser. Du kan distribuera om och starta konfigurationen som är lätt att köra när du behöver utföra delnings- eller sammanslagningsåtgärder.

Övervakning

Statustabeller

Tjänsten för delad sammanslagning innehåller tabellen RequestStatus i metadatalagringsdatabasen för övervakning av slutförda och pågående begäranden. Tabellen visar en rad för varje begäran om delad sammanfogning som har skickats till den här instansen av split-merge-tjänsten. Den ger följande information för varje begäran:

• Tidsstämpel

  Tid och datum då begäran startades.

• OperationId

  Ett GUID som unikt identifierar begäran. Den här begäran kan också användas för att avbryta åtgärden medan den fortfarande pågår.

• Status

  Begärans aktuella tillstånd. För pågående begäranden visas även den aktuella fasen där begäran är.

• CancelRequest

  En flagga som anger om begäran har avbrutits.

• Framsteg

  En procentuell uppskattning av slutförandet för åtgärden. Värdet 50 anger att åtgärden är cirka 50 % klar.

• Detaljer

  Ett XML-värde som ger en mer detaljerad förloppsrapport. Förloppsrapporten uppdateras regelbundet när uppsättningar med rader kopieras från källa till mål. I händelse av fel eller undantag innehåller den här kolumnen även mer detaljerad information om felet.

Microsoft Azure Diagnostics

Tjänsten för delad sammanslagning använder Azure Diagnostics baserat på Azure SDK 2.5 för övervakning och diagnostik. Du styr diagnostikkonfigurationen enligt beskrivningen här: Aktivera diagnostik i Azure Cloud Services och virtuella datorer. Nedladdningspaketet innehåller två diagnostikkonfigurationer – en för webbrollen och en för arbetsrollen. Den innehåller definitioner för att logga prestandaräknare, IIS-loggar, Windows-händelseloggar och programhändelseloggar med delad koppling.

Distribuera diagnostik

Kommentar

Den här artikeln använder Azure Az PowerShell-modulen, som är den rekommenderade PowerShell-modulen för interaktion med Azure. För att komma igång med Az PowerShell kan du läsa artikeln om att installera Azure PowerShell. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Viktigt!

PowerShell Azure Resource Manager-modulen stöds fortfarande, men all framtida utveckling gäller för Az.Sql-modulen. Dessa cmdletar finns i AzureRM.Sql. Argumenten för kommandona i Az-modulen och i AzureRm-modulerna är väsentligen identiska.

Om du vill aktivera övervakning och diagnostik med hjälp av diagnostikkonfigurationen för webb- och arbetsrollerna som tillhandahålls av NuGet-paketet kör du följande kommandon med Azure PowerShell:

$storageName = "<azureStorageAccount>"
$key = "<azureStorageAccountKey"
$storageContext = New-AzStorageContext -StorageAccountName $storageName -StorageAccountKey $key
$configPath = "<filePath>\SplitMergeWebContent.diagnostics.xml"
$serviceName = "<cloudServiceName>"

Set-AzureServiceDiagnosticsExtension -StorageContext $storageContext `
    -DiagnosticsConfigurationPath $configPath -ServiceName $serviceName `
    -Slot Production -Role "SplitMergeWeb"

Set-AzureServiceDiagnosticsExtension -StorageContext $storageContext `
    -DiagnosticsConfigurationPath $configPath -ServiceName $serviceName `
    -Slot Production -Role "SplitMergeWorker"

Mer information om hur du konfigurerar och distribuerar diagnostikinställningar finns här: Aktivera diagnostik i Azure Cloud Services och virtuella datorer.

Hämta diagnostik

Du kan enkelt komma åt din diagnostik från Visual Studio Server Explorer i Azure-delen av serverutforskarens träd. Öppna en Visual Studio-instans och i menyraden klickar du på Visa och Serverutforskaren. Klicka på Azure-ikonen för att ansluta till din Azure-prenumeration. Navigera sedan till Azure –> Storage –><your storage account> –> Tabeller –> WADLogsTable. Mer information finns i Server Explorer.

WADLogsTable som är markerad i bilden ovan innehåller detaljerade händelser från split-merge-tjänstens programlogg. Observera att standardkonfigurationen för det nedladdade paketet är inriktad på en produktionsdistribution. Därför är intervallet då loggar och räknare hämtas från tjänstinstanserna stort (5 minuter). För testning och utveckling sänker du intervallet genom att justera diagnostikinställningarna för webben eller arbetsrollen efter dina behov. Högerklicka på rollen i Visual Studio Server Explorer (se ovan) och justera sedan överföringsperioden i dialogrutan för konfigurationsinställningarna för diagnostik:

Prestanda

I allmänhet är bättre prestanda att förvänta sig från högre, mer högpresterande tjänstnivåer. Högre I/O-, CPU- och minnesallokeringar för de högre tjänstnivåerna gynnar de masskopierings- och borttagningsåtgärder som används av split-merge-tjänsten. Därför bör du öka tjänstnivån bara för dessa databaser under en definierad, begränsad tidsperiod.

Tjänsten utför också valideringsfrågor som en del av sina normala åtgärder. Dessa valideringsfrågor söker efter oväntad förekomst av data i målintervallet och ser till att alla åtgärder för att dela/sammanfoga/flytta startar från ett konsekvent tillstånd. Dessa frågor fungerar över fragmenteringsnyckelintervall som definieras av åtgärdens omfattning och batchstorleken som tillhandahålls som en del av begärandedefinitionen. De här frågorna fungerar bäst när det finns ett index som har partitioneringsnyckeln som inledande kolumn.

Dessutom gör en unik egenskap med partitioneringsnyckeln som inledande kolumn att tjänsten kan använda en optimerad metod som begränsar resursförbrukningen när det gäller loggutrymme och minne. Den här unikhetsegenskapen krävs för att flytta stora datastorlekar (vanligtvis över 1 GB).

Så här uppgraderar du

1. Följ stegen i Distribuera en tjänst för delad sammanslagning.
2. Ändra konfigurationsfilen för molntjänsten för distributionen av delad sammanfogning så att den återspeglar de nya konfigurationsparametrarna. En ny obligatorisk parameter är informationen om det certifikat som används för kryptering. Ett enkelt sätt att göra detta är att jämföra den nya konfigurationsmallfilen från nedladdningen med din befintliga konfiguration. Se till att du lägger till inställningarna för DataEncryptionPrimaryCertificateThumbprint och DataEncryptionPrimary för både webb- och arbetsrollen.
3. Innan du distribuerar uppdateringen till Azure kontrollerar du att alla åtgärder för delad sammanslagning som körs för närvarande har slutförts. Du kan enkelt göra detta genom att fråga tabellerna RequestStatus och PendingWorkflows i metadatadatabasen för delad sammanslagning för pågående begäranden.
4. Uppdatera din befintliga molntjänstdistribution för delningskoppling i din Azure-prenumeration med det nya paketet och den uppdaterade tjänstkonfigurationsfilen.

Du behöver inte etablera en ny metadatadatabas för delningssammanslagning för att uppgradera. Den nya versionen uppgraderar automatiskt din befintliga metadatadatabas till den nya versionen.

Metodtips och felsökning

• Definiera en testklientorganisation och träna de viktigaste åtgärderna för att dela/sammanfoga/flytta med testklientorganisationen över flera shards. Kontrollera att alla metadata har definierats korrekt i fragmentkartan och att åtgärderna inte bryter mot begränsningar eller sekundärnycklar.
• Håll testklientdatastorleken över den maximala datastorleken för din största klientorganisation för att säkerställa att du inte stöter på problem med datastorleken. Detta hjälper dig att utvärdera en övre gräns på den tid det tar att flytta en enskild klientorganisation runt.
• Kontrollera att schemat tillåter borttagningar. Split-merge-tjänsten kräver möjligheten att ta bort data från källskärvan när data har kopierats till målet. Till exempel kan borttagningsutlösare hindra tjänsten från att ta bort data på källan och kan orsaka att åtgärder misslyckas.
• Partitioneringsnyckeln ska vara den inledande kolumnen i primärnyckeln eller den unika indexdefinitionen. Det säkerställer bästa prestanda för valideringsfrågorna för delning eller sammanslagning och för de faktiska dataförflyttnings- och borttagningsåtgärderna som alltid körs på partitioneringsnyckelintervall.
• Samordna din tjänst för delningssammanslagning i regionen och datacentret där databaserna finns.

Ytterligare resurser

Använder du inte elastiska databasverktyg än? Kolla in vår komma igång-guide. Om du har frågor kan du kontakta oss på microsofts Q&A-frågesida för SQL Database och för funktionsförfrågningar, lägga till nya idéer eller rösta på befintliga idéer i SQL Database-feedbackforumet.