Dela via

Lär dig hur du felsöker U-SQL-körningsfel på grund av körningsändringar

  • Artikel

Viktigt

Azure Data Lake Analytics tillbaka den 29 februari 2024. Läs mer med det här meddelandet.

För dataanalys kan din organisation använda Azure Synapse Analytics eller Microsoft Fabric.

Azure Data Lake U-SQL-körningen, inklusive kompilatorn, optimeraren och jobbhanteraren, är det som bearbetar din U-SQL-kod.

Välja U-SQL-körningsversion

När du skickar U-SQL-jobb från antingen Visual Studio, ADL SDK eller Azure Data Lake Analytics-portalen använder jobbet den för närvarande tillgängliga standardkörningen. Nya versioner av U-SQL-körningen släpps regelbundet och innehåller både mindre uppdateringar och säkerhetskorrigeringar.

Du kan också välja en anpassad körningsversion. antingen för att du vill prova en ny uppdatering, behöver stanna kvar på en äldre version av en körning eller har fått en snabbkorrigering för ett rapporterat problem där du inte kan vänta på den vanliga nya uppdateringen.

Varning

Om du väljer en körning som skiljer sig från standardinställningen kan du bryta dina U-SQL-jobb. Använd endast dessa andra versioner för testning.

I sällsynta fall kan Microsoft Support fästa en annan version av en körning som standard för ditt konto. Se till att du återställer det här stiftet så snart som möjligt. Om du förblir fäst på den versionen upphör den att gälla vid ett senare tillfälle.

Övervaka jobbens U-SQL-körningsversion

Du kan se historiken för vilken körningsversion dina tidigare jobb har använt i ditt kontos jobbhistorik via Visual Studio-jobbwebbläsaren eller Azure Portal jobbhistorik.

  1. I Azure Portal går du till ditt Data Lake Analytics-konto.
  2. Välj Visa alla jobb. En lista över alla aktiva och nyligen slutförda jobb i kontot visas.
  3. Du kan också välja Filter som hjälper dig att hitta jobben efter tidsintervall, jobbnamn och författare .
  4. Du kan se körningen som används i de slutförda jobben.

Visa körningsversionen av ett tidigare jobb

De tillgängliga körningsversionerna ändras med tiden. Standardkörningen kallas alltid "standard" och vi behåller åtminstone den tidigare körningen tillgänglig under en viss tid och gör särskilda körningar tillgängliga av olika skäl. Explicit namngivna körningsmiljöer följer vanligtvis följande format (kursiv stil används för variabeldelar och [] anger valfria delar):

release_YYYYMMDD_adl_buildno[_modifier]

Till exempel innebär release_20190318_adl_3394512_2 den andra versionen av bygget 3394512 av körningsversionen den 18 mars 2019 och release_20190318_adl_3394512_private innebär en privat version av samma version. Obs! Datumet är relaterat till när den senaste incheckningen har gjorts för den versionen och inte nödvändigtvis det officiella utgivningsdatumet.

Felsöka problem med U-SQL-körningsversion

Det finns två möjliga körningsversionsproblem som du kan stöta på:

  1. Ett skript eller viss användarkod ändrar beteendet från en version till en annan. Sådana icke-bakåtkompatibla ändringar kommuniceras normalt i förväg med publiceringen av viktig information. Om du stöter på en sådan icke-bakåtkompatibel ändring kontaktar du Microsoft Support för att rapportera det här icke-bakåtkompatibla beteendet (om det inte har dokumenterats ännu) och skicka jobben mot den äldre körningsversionen.

  2. Du har använt en nondefault-körning antingen explicit eller implicit när den har fästs på ditt konto, och den körningen har tagits bort efter en tid. Om du stöter på saknade körningar uppgraderar du skripten så att de körs med den aktuella standardkörningen. Kontakta Microsoft Support om du behöver mer tid

Kända problem

  1. Om du refererar till Newtonsoft.Json-filen version 12.0.3 eller senare i ett USQL-skript orsakas följande kompileringsfel:

    "Vi är ledsna; jobb som körs i ditt Data Lake Analytics-konto kommer troligen att köras långsammare eller misslyckas. Ett oväntat problem hindrar oss från att automatiskt återställa den här funktionen till ditt Azure Data Lake Analytics-konto. Azure Data Lake-tekniker har kontaktats för att undersöka saken."

    Var anropsstacken ska innehålla:
    System.IndexOutOfRangeException: Index was outside the bounds of the array.
    at Roslyn.Compilers.MetadataReader.PEFile.CustomAttributeTableReader.get_Item(UInt32 rowId)
    ...

    Lösning: Använd Newtonsoft.Json-filen v12.0.2 eller lägre.

  2. Kunder kan se temporära filer och mappar i sin butik. De skapas som en del av den normala jobbkörningen, men tas vanligtvis bort innan kunderna ser dem. Under vissa omständigheter, som är sällsynta och slumpmässiga, kan de förbli synliga. De tas så småningom bort och räknas aldrig som en del av användarlagringen eller genererar någon form av avgifter som helst. Beroende på kundernas jobblogik kan de orsaka problem. Om jobbet till exempel räknar upp alla filer i mappen och sedan jämför fillistor kan det misslyckas på grund av att de oväntade temporära filerna finns. På samma sätt, om ett nedströmsjobb räknar upp alla filer från en viss mapp för vidare bearbetning, kan det också räkna upp de temporära filerna.

    Lösning: En korrigering identifieras i körningen där temporära filer lagras i temp-mappen på kontonivå i stället för den aktuella utdatamappen. De temporära filerna skrivs i den nya temp-mappen och tas bort i slutet av jobbkörningen.
    Eftersom den här korrigeringen hanterar kunddata är det viktigt att korrigeringen verifieras väl i MSFT innan den släpps. Den här korrigeringen förväntas vara tillgänglig som betakörning i mitten av år 2021 och som standardkörning under andra halvåret 2021.

Se även