Asynkron bearbetning av kaskadtransaktioner
Vissa transaktioner kan konfigureras så att alla relaterade poster överlappar varandra. Detta innebär att en ändring i en överordnad post aktiveras (sprids nedåt) alla underordnade poster. Kaskadrelationer konfigureras på tabellnivån. Mer information om kaskadrelationer finns i Konfigurera kaskadbeteende för tabellförhållande.
Synkrona lägen jämfört med asynkrona lägen
Som standard utförs kaskadåtgärder som en synkron transaktion. För en synkron kaskadtransaktion identifieras alla påverkade poster av systemet. När posterna bearbetas låses de av systemet. När alla ändringar har slutförts låses posterna upp och transaktionen slutförs.
Synkrona transaktioner med ett stort antal poster kan orsaka prestandaproblem i miljöer då längre transaktioner misslyckas på grund av timeout-fel i servern. Posterna låses och förhindrar andra jobb och användartransaktioner som körs på samma poster från att köras. Längre transaktioner kan också resultera i en eftersläpning av väntande transaktioner och förfrågningar som försämrar systemets prestanda och kan orsaka avbrott i arbetet.
Om det uppstår timeout eller försämrad prestanda i en miljö under pågående synkrona åtgärder, kan din miljö dra nytta av att aktivera det asynkrona läget. De viktigaste skillnaderna mellan lägena beskrivs här i följande tabell.
| Synkront läge | Asynkront läge |
|---|---|
| Det går inte att utföra andra jobb för hela uppsättningen valda poster (direkt eller sammanhängande) tills kaskadåtgärden är slutförd. | För tilldelning, borttagning och sammanslagning batchas kaskadändringar så att endast de poster som bearbetas låses i batchen. Detta gör att andra jobb kan utföras under hela sammanhängande ändringar. |
| När jobbet har slutförts för alla data visas det nya önskade värdet. | När du kör varje slutförd batch visas det önskade värdet. Detta innebär att det kan finnas en tid då en del data visar det önskade värdet och vissa visar det ursprungliga värdet tills hela åtgärden har slutförts. Detta kallas för "eventuell konsekvens". |
| Om en enstaka post misslyckas återställs alla data till det ursprungliga värdet. Återställningen kräver att du redigerar alla slutförda poster igen, vilket tar ytterligare tid. | Om ett enskilt jobb misslyckas görs ett nytt försök att utföra åtgärden. Om jobbet inte kan slutföras registreras felet i området systemuppgifter. Observera att om du har slutfört posterna behålls det nya värdet. |
| Om en av posterna i kaskadlistan har ett värde som skiljer sig från det förväntade värdet kommer jobbet att misslyckas och sedan återställas. Om t.ex startposten tillhör Ägare 1 och kaskadåtgärden vill ändra till Ägare 2. Om en av posterna som är relaterade till den underordnade har ändrats till Ägare 3 eller tas bort innan låset görs återställs hela jobbet. | För Tilldela fungerar alltid åtgärden i överskrivningsläge och ändrar det aktuella värdet till det nya värdet utifrån den överordnade underordnade relationen. Det finns inga misslyckade jobb p.g.a. ett ursprungligt värde som inte matchar. För Ta bort: Om en post som förväntades ingå i en uppsättning saknas, betraktas alla poster fram till felet som slutförda. Användaren eller administratören kan köra om det misslyckade jobbet, vilket gör att jobbet beräknas om i syfte att låta det fortsätta utan den saknade posten. För Sammanslå, om det finns ett problem med en post som saknas, utförs jobbet på nytt och körs utan den saknade posten. |
Asynkront läge och plugin-program
När en kaskadtransaktion uppfyller tröskelvärdet för inkluderade poster och inte har några plugin-program associerade med posterna bearbetas posterna asynkront.
| Åtgärd | Threshold |
|---|---|
| Tilldela | 1 000 poster |
| Delete | 10 000 poster |
| Slå ihop | 1 000 poster |
Om det finns ett plugin-program som har tilldelats en post i den asynkrona batchen körs den enskilda posten som uppdateras eller tas bort tillsammans med alla associerade plugin-program för posten i synkront läge. Detta inträffar som en del av en transaktion innan det går att flytta till nästa post i den asynkrona batchen.
Om ett plugin-program inuti den asynkrona transaktionen utlöser en ny kaskadborttagning eller tilldelning, körs den nya kaskadtransaktionen alltid synkront inom den aktuella asynkrona transaktionen. Detta förhindrar att ha flera lager av asynkrona transaktioner.
Spåra förloppet för den asynkrona åtgärden
Administratörer kan övervaka hanteringen av asynkrona åtgärder i området inställningar.
Logga in på Power Platform administrationscenter.
Välj miljöer i navigeringsområdet. Välj sedan vilken miljö du vill ha.
Välj Inställningar, expandera Granskning och loggar och välj sedan Systemuppgifter.
Kaskadåtgärder visas i vyn systemuppgifter.
Om du endast vill visa relaterade åtgärder väljer du Vy och väljer Kaskadåtgärder.
Kaskadåtgärder har någon av följande status:
- Slutförd: Alla poster i kaskadtransaktioner har slutförts.
- Pågår: Kaskadändringar pågår.
- Misslyckades: Efter flera försök har vissa kaskadändringar misslyckats.
Kommentar
Det går inte att avbryta ett asynkront kaskadjobb. Du måste vänta på att den ska slutföras genom att ange statusen slutförd eller misslyckad.
När du öppnar en kaskadåtgärd visas följande:
Hur många försök har inträffat för en viss transaktion.
Datum och tid för skapad och slutförd.
Som skapade jobbet.
Alla meddelanden som är associerade med jobbet, t. ex orsaker till misslyckanden eller undantag.
Vilka kaskadtransaktioner kan bearbetas asynkront?
Tilldelnings-, borttagnings-och sammanslagningstransaktioner kan bearbetas asynkront.
Kommentar
Andra transaktioner, t.ex. dela/ta bort delning, sammanslagningsvy och ny överordnad övervägs i nuläget för asynkron bearbetning.
Felsöka problem med asynkrona kaskadåtgärder
När synkrona kaskadjobb havererar stoppas de och alla ändringar återställs så att inga av posterna innehåller de begärda ändringarna. Detta kan ta lång tid eftersom återställningar kan ta lika länge som det ursprungliga försöket och ett nytt försök att starta åtgärden börjar om från den första posten.
Asynkrona åtgärder kommer att upprepas flera gånger om ett fel uppstår. I de flesta fall kommer ett nytt försök att köra jobbet att bli framgångsrikt, och jobbet kan sedan slutföras. I vissa sällsynta fall löses inte problemet genom att prova igen. När detta inträffar pausas ett asynkront jobb, och administratören och användaren kan felsöka problemet och återuppta jobbet från den plats där det pausades.
Vanliga orsaker till problem vid överlappande åtgärder
Vanliga orsaker till att problem uppstår vid bearbetning av kaskadåtgärder är:
- Undantag för plugin-program
- Säkerhetsundantag
Undantag för plugin-program
Plugin-program läggs till i behandlingen av kaskadåtgärder i syfte att vidta specifika åtgärder när ändringar görs i en post, till exempel att skicka ett e-postmeddelande eller att utlösa en annan uppdatering på andra poster. Dessa kan tillhandahållas av tredje part eller vara utvecklade inom företaget. Om ett plugin-program genererar ett undantag kommer kaskadåtgärden inte att lyckas. Beroende på skälet till undantaget kan ett nytt försök lösa problemet. Om det asynkrona kaskadjobbet har pausats på grund av fel verifierar du alla plugin-program som är associerade med åtgärderna för att se till att de inte genererar undantag. När problemet är åtgärdat kan jobbet återupptas.
Säkerhetsundantag
Säkerhetsundantag inträffar när användaren som utförde kaskadåtgärden inte har tillräckliga privilegier för att göra en ändring i en eller flera poster, eller också inaktiveras eller tas användaren bort från systemet.
Om användaren fortfarande finns i systemet verifierar du att de har de privilegier som krävs för att ändra posterna och att de har behörighet att utföra de angivna åtgärderna. När problemet är löst fortsätter du jobbet.
Om användaren har inaktiverats eller tagits bort från systemet löser du problemet genom att återaktivera eller lägga till användaren på nytt och sedan återuppta jobbet. Om användaren emellertid måste tas bort eller inaktiveras eller inte ska ha behörighet för åtgärderna eller posterna ska jobbet annulleras och startas om av någon med rätt behörigheter.
För andra åroblem med jobb som inte fungerar korrekt, kontakta Microsoft support. Mer information: Supportöversikt
Felsökning av problem med filborttagning under kaskadsammanslagning
Om du får problem med kaskadsammanslagningar på grund av att filer tas bort när jobbet körs kan du hoppa över den överordnade kontrollen. Detta gör att sammanslagningen kan fortsätta även om någon tar bort en post från uppsättningen medan jobbet körs i bakgrunden. För att göra detta: När du väljer att slå ihop poster rensar du (längst ner i sammanslagningsfönstret) alternativet Överordnad kontroll aktiverad som standard. Avmarkera om du vill ignorera överordnad kontroll.
Exempel på Slå samman post
Anta att du har konton med en relation till en kontakt, som har en relation till order. Du vill slå ihop två kontoposter.
Om jobbet körs utan problem tilldelar sammanslagningen alla relaterade kontakter och dessas order till målkontot.
Om en annan användare tar bort en relaterad kontaktpost i samband med postsammanslagningen men det fortfarande finns orderposter som är relaterade till kontaktposten kommer sammanslagningen att misslyckas, detta eftersom en överordnad post till en underordnad saknas. Om du väljer att hoppa över den överordnade kontrollen under postsammanslagningen slås order med den saknade kontaktposten ihop med målkontoposten. Däremot tilldelas inte målkontot några relaterade kontaktposter, och jobbet kommer att slutföras.
Koppla ihop lås som förhindrar andra åtkomständringar
Med åtgärden Kaskadkoppling får den nya ägaren av den underordnade tabellen åtkomst. För att göra detta öppnar och gör åtgärden Kaskadkoppling ändringar i tabellen Huvudobjekt, vilket kräver ett lås. Om en kopplingsåtgärd innehåller många poster (baserat på kaskadrelationen) kan det här spärren finnas på plats under en längre tid. Detta kan resultera i ett fel om en åtgärd försöker ge/återkalla åtkomst till en orelaterad post medan kopplingen körs. Om det händer kan du prova att köra kopplingen i timmar så att blockeringen kan minskas.