Vanlige spørsmål for Mirroring Snowflake i Microsoft Fabric

For Snowflake bruker vi en landingssone til å lagre både øyeblikksbildet og endre data til OneLake, for å forbedre ytelsen når vi konverterer disse filene i landingssonene til deltavertiparquet.

Administrerte tabeller, isfjelltabeller og visninger støttes for replikasjon. Eksterne, transiente, midlertidige og dynamiske tabeller støttes ikke. For isfjelltabeller kreves en lagringstilkobling til den underliggende isfjelltabelllagringen under konfigurasjonen. For detaljer om kjente problemer med visninger (som datatypekartlegging), se Begrensninger.

Velg tannhjulet for innstillingene, og velg deretter Behandle tilkobling og gatewayer. Du kan også slette eksisterende tilkoblinger fra denne siden.

Følgende autentiseringsmetoder støttes:

• Brukernavn og passord — Snowflake native autentisering
• Microsoft Entra ID (SSO) — Single sign-on via Entra ID
• Nøkkelparautentisering — RSA-nøkkelpar for tjenestekontoscenarier

1. Gjenbruk et eksisterende lager. Konfigurer speiling til å bruke det samme Snowflake-lageret som applikasjonene dine allerede bruker for å oppdatere kildetabellene. Dette unngår belastningen ved å vekke et separat, dedikert speilingslager. Når applikasjonen din oppdaterer en tabell, plukker speilreplikatoren opp endringer nesten umiddelbart mens lageret fortsatt er aktivt. 2. Speil bare tabellene du trenger. Unngå å speile en hel database når du bare trenger et delsett av tabeller. Storskala speiling kan føre til betydelig Snowflake-forbruk og økning i Fabric-kapasitet. 3. Følg med på uventede gjensåinger. En ny leser hele tabellen på nytt og pådrar seg beregningskostnad proporsjonal med størrelsen. Sjekk siden Mirroring Status for tabeller som gjentatte ganger viser oppførsel ved første kopiering. 4. Bruk Snowflake-budsjetter og kredittgrenser. Sett Snowflake-ressursovervåkere og budsjetter til å begrense beregningskostnader knyttet til speiling.

Fabric tar ikke betalt for inngående avgifter til OneLake for Mirroring.

Hvis du driftes utenfor Azure, kan du se Snowflake og skydokumentasjonen for utgående kostnader. Hvis det driftes i Azure, men i et annet område enn Fabric-kapasiteten, blir datainngangen belastet. Hvis det driftes i Azure i samme område, er det ingen datainngang.

No. Speiling kjører kontinuerlig og støtter for øyeblikket ikke konfigurasjon av replikasjonsplaner eller tidsbaserte vinduer. Replikatoren spør kontinuerlig etter endringer, noe som genererer kontinuerlig Snowflake-beregningsbruk. Hvis du trenger å begrense beregningen i visse perioder, kan du manuelt stoppe og starte speilingen på nytt — men merk at omstart utløser en full omstart av alle speilede tabeller.

Det avhenger av størrelsen på dataene som hentes inn.

Nær ventetid i sanntid.

Ja, tabeller er alle v-bestilte deltatabeller.

Se Monitor Fabric Mirror-replikering.

Ja, vi støtter speiling gjennom en lokal datagateway og gjennom en virtuelt nettverk (VNet) Data Gateway.

Dataene fra kildetabeller vil bli initialisert på nytt. Hver gang du stopper og starter, hentes hele tabellen på nytt.

Vi slutter å speile den bestemte tabellen og sletter den fra OneLake.

Nei, vi fjerner bare strømmingstabellene.

Ja, det kan du, men det trenger du ikke. Når dataene er i Fabric, kan de deles derfra.

Ja, bestemte tabeller kan velges under Speiling-konfigurasjonen.

En resed (full datainnlasting) utløses av en av følgende:

• DDL-endringer som endrer DDL-tidsstempelet til en tabell, for eksempel operasjoner ALTER TABLE som legger til eller fjerner kolonner.
• Skjemamodifikasjonsverktøy som dbt som slipper og gjenskaper tabeller på en tidsplan.
• Stopper og starter speiling på nytt gjennom Fabric-portalen eller API-et.
• En utvidet kapasitetspause. Hvis Fabric-kapasiteten er satt på pause over lengre tid, kan speiling starte tilbake når den gjenopptas.

Hvis du ser tabeller gjentatte ganger gå gjennom initial copy (reseed) i stedet for inkrementell synkronisering:

1. Sjekk etter endringer i skjemaet oppstrøms. Verifiser om et verktøy som dbt endrer tabelldefinisjoner på en gjentakende tidsplan. Selv små DDL-endringer kan utløse en ny seeding.
2. Se gjennom siden for speilstatus. Se etter tabeller som viser gjentatte initialkopieringstidsstempler med jevne mellomrom.
3. Pause skjemaendringer under aktiv speiling. Hvis DBT-kjøringer er årsaken, planlegg dem under vedlikeholdsvinduer, eller pause speiling før du kjører skjemaendringer.
4. Overvåk bruken av Snowflake-lageret. Sjekk Snowflake-kontobruksvisningene for å se om speilingsrelaterte spørringer dominerer beregningen.
5. Husk at hver Reseed behandler hele tabelldataene og pådrar seg Snowflake-beregningskostnader proporsjonalt med tabellstørrelsen. proporsjonal med bordstørrelsen.

No.

Nei, data er ikke iscenesatt utenfor kundemiljøet, det er iscenesatt i kundens OneLake.

En Power BI Premium-, Fabric-kapasitet eller prøvekapasitet kreves. Hvis du vil ha mer informasjon om lisensiering, kan du se Microsoft Fabric-lisenser.

Fabric compute som brukes til å replikere dataene dine til Fabric OneLake, er gratis. Lagringskostnaden for speiling er gratis opp til en grense basert på kapasitet. Hvis du vil ha mer informasjon, kan du se Kostnader for speiling og Microsoft Fabric-priser. Databehandlingen for spørring av data ved hjelp av SQL, Power BI eller Spark belastes med vanlige priser.

Relatert innhold

• Hva er speiling i stoff?
• Oversikt over Snowflake-kobling