Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A Power BI XMLA-végpontjai a natív Analysis Services kommunikációs protokollra támaszkodnak a Power BI szemantikai modelljeihez való hozzáféréshez. Emiatt az XMLA-végpontok hibaelhárítása ugyanaz, mint egy tipikus Analysis Services-kapcsolat hibaelhárítása. A Power BI-specifikus függőségek között azonban vannak különbségek.
Mielőtt elkezdené
Az XMLA-végpontok hibaelhárítása előtt mindenképpen tekintse át az XMLA-végponttal való szemantikai modellkapcsolat alapjait. Itt a leggyakoribb XMLA-végponthasználati esetek szerepelnek. A Power BI egyéb hibaelhárítási útmutatói, például az átjárók hibaelhárítása – a Power BI és az Elemzés hibaelhárítása az Excelben – szintén hasznosak lehetnek.
Az XMLA-végpont engedélyezése
Az XMLA-végpont engedélyezhető a Power BI Premium, a Felhasználónkénti Prémium és a Power BI Embedded-kapacitásokon is. Kisebb kapacitások, például a csak 2,5 GB memóriával rendelkező A1-kapacitás esetén a Kapacitás beállításaiban hiba jelenhet meg, amikor az XMLA-végpontot olvasási/írási értékre állítja, majd az Alkalmaz lehetőséget választja. A hiba a következő: "Probléma történt a számítási feladat beállításaival. Próbálkozzon újra egy kis idő múlva."
Íme néhány kipróbálandó dolog:
- A kapacitáson lévő egyéb szolgáltatások( például adatfolyamok) memóriahasználatát legfeljebb 40%-ra korlátozhatja, vagy teljesen letilthat egy szükségtelen szolgáltatást.
- Frissítse a kapacitást egy nagyobb termékváltozatra. Az A1-ről egy A3-kapacitásra való frissítés például anélkül oldja meg ezt a konfigurációs problémát, hogy le kellene tiltania az adatfolyamokat.
Ne feledje, hogy a bérlőszintű exportálási adatbeállítást is engedélyeznie kell a Power BI felügyeleti portálján. Ez a beállítás az Elemzés az Excelben funkcióhoz is szükséges.
Ügyfélkapcsolat létrehozása
Az XMLA-végpont engedélyezése után érdemes tesztelni a kapacitáson lévő munkaterülethez való kapcsolódást. További információ: Csatlakozás prémium szintű munkaterülethez. Emellett mindenképpen olvassa el a kapcsolati követelmények című szakaszt, amely hasznos tippeket és információkat tartalmaz az XMLA aktuális csatlakozási korlátairól.
Csatlakozás szolgáltatási főazonosítóval
Ha engedélyezte a bérlői beállításokat, hogy lehetővé tegyék a szolgáltatási főfelhasználói fiókok számára a Power BI API-k használatát, a Szolgáltatási főfelhasználói fiókok engedélyezése című cikkben leírtak szerint, egy szolgáltatási főfelhasználói fiók használatával csatlakozhat egy XMLA-végponthoz. Ne feledje, hogy a szolgáltatásazonosító a munkaterületen vagy a szemantikai modell szintjén ugyanolyan szintű hozzáférési engedélyeket igényel, mint a normál felhasználók.
A szolgáltatási hitelesítő használatához mindenképpen adja meg az alkalmazás azonosító adatait a kapcsolati karakterláncban a következőképpen:
Felhasználói azonosító - alkalmazás:appid@tenantid
Jelszó
cert:ujjlenyomat (biztonsági célokra ajánlott)
Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=cert:<thumbprint>;alkalmazás titkos kódja
Data Source=powerbi://api.powerbi.com/v1.0/myorg/Contoso;Initial Catalog=PowerBI_Dataset;User ID=app:<appid>;Password=<secret>;
Ha a következő hibaüzenet jelenik meg:
A fiók információk hiányossága miatt nem tudunk kapcsolódni a szemantikai modellhez. Szolgáltatási entitások esetén adja meg a bérlőazonosítót az alkalmazásazonosítóval együtt az app:<appId>@<tenantId> formátumban, majd próbálkozzon újra.
Győződjön meg arról, hogy a bérlőazonosítót és az alkalmazásazonosítót a megfelelő formátumban adja meg.
Az alkalmazásazonosító megadása a bérlőazonosító nélkül is érvényes. Ebben az esetben azonban az myorg adatforrás URL-címében szereplő aliast a tényleges bérlőazonosítóra kell cserélni. A Power BI ezután megkeresheti a szolgáltatási főazonosítót a megfelelő bérlőnél. Ajánlott eljárásként azonban használja az myorg aliast, és adja meg a bérlőazonosítót az alkalmazásazonosítóval együtt a Felhasználói azonosító paraméterben.
Csatlakozás a Microsoft Entra B2B-vel
A Power BI-ban a Microsoft Entra vállalati verzió (B2B) támogatásával külső vendégfelhasználók számára is hozzáférést biztosíthat a szemantikai modellekhez az XMLA-végponton keresztül. Győződjön meg arról, hogy a Tartalom megosztása külső felhasználókkal beállítás engedélyezve van a Power BI Felügyeleti portálon. További információ: Power BI-tartalom terjesztése külső vendégfelhasználóknak a Microsoft Entra B2B-vel.
Szemantikai modell üzembe helyezése
Táblázatos modellprojektet helyezhet üzembe a Visual Studióban (SSDT) egy prémium szintű kapacitáshoz rendelt munkaterületen, ugyanúgy, mint az Azure Analysis Services kiszolgálói erőforrásában. Az üzembe helyezéskor azonban további szempontokat is figyelembe kell venni. Mindenképpen tekintse át a Modellprojektek üzembe helyezése a Visual Studióból (SSDT) című szakaszt az XMLA-végpont cikk szemantikai modellkapcsolatában.
Új modell üzembe helyezése
Az alapértelmezett konfigurációban a Visual Studio megpróbálja feldolgozni a modellt az üzembe helyezési művelet részeként, hogy adatokat töltsön be a szemantikai modellbe az adatforrásokból. A Modellprojektek üzembe helyezése a Visual Studióból (SSDT) című cikkben leírtak szerint ez a művelet meghiúsulhat, mert az adatforrás hitelesítő adatai nem adhatók meg az üzembe helyezési művelet részeként. Ha azonban az adatforrás hitelesítő adatai még nincsenek meghatározva egyik meglévő szemantikai modellhez sem, akkor a Power BI felhasználói felületén (Szemantikai modellek>beállításai>szerkesztése) meg kell adnia az adatforrás hitelesítő adatait a szemantikai modell beállításai között. Az adatforrás hitelesítő adatainak definiálása után a Power BI automatikusan alkalmazhatja a hitelesítő adatokat erre az adatforrásra minden új szemantikai modell esetében, miután a metaadatok üzembe helyezése sikeres volt, és a szemantikai modell létrejött.
Ha a Power BI nem tudja az új szemantikai modellt az adatforrás hitelesítő adataihoz kötni, hibaüzenet jelenik meg: "Nem lehet feldolgozni az adatbázist. Ok: Nem sikerült menteni a módosításokat a kiszolgálóra." hibakód: "DMTS_DatasourceHasNoCredentialError", ahogy az alább látható:
A feldolgozási hiba elkerülése érdekében állítsa az
Új projekt egy meglévő szemantikai modellből
Nem támogatott új táblázatos projekt létrehozása a Visual Studióban a metaadatok meglévő szemantikai modellből való importálásával. A szemantikai modellhez azonban csatlakozhat az SQL Server Management Studio használatával, kiszkriptezheti a metaadatokat, és más táblázatos projektekben is felhasználhatja.
Szemantikai modell migrálása a Power BI-ba
Javasoljuk, hogy adja meg a táblázatos modellek 1500 (vagy magasabb) kompatibilitási szintjét. Ez a kompatibilitási szint a legtöbb képességet és adatforrástípust támogatja. A későbbi kompatibilitási szintek visszamenőlegesen kompatibilisek a korábbi szintekkel.
Támogatott adatszolgáltatók
Az 1500-es kompatibilitási szinten a Power BI a következő adatforrástípusokat támogatja:
- Szolgáltatói adatforrások (örökölt kapcsolati karakterlánc a modell metaadataiban).
- Strukturált adatforrások (az 1400-es kompatibilitási szinttel vezették be).
- Adatforrások beágyazott M deklarációi (ahogy a Power BI Desktop deklarálja őket).
Ajánlott strukturált adatforrásokat használni, amelyeket a Visual Studio alapértelmezés szerint létrehoz az adatfolyam importálása során. Ha azonban egy szolgáltatói adatforrást használó meglévő modellt szeretne migrálni a Power BI-ba, győződjön meg arról, hogy a szolgáltató adatforrása egy támogatott adatszolgáltatóra támaszkodik. Pontosabban az SQL Serverhez készült Microsoft OLE DB-illesztőt és a bármely külső ODBC-illesztőprogramot. Az SQL Serverhez készült OLE DB-illesztőprogram esetében az adatforrás definícióját az SQL Server .NET-keretrendszer adatszolgáltatójának kell átállítania. Külső ODBC-illesztőprogramok, amelyek esetleg nem érhetők el a Power BI szolgáltatásban, esetén strukturált adatforrás-definícióra kell váltania.
Azt is javasoljuk, hogy cserélje le az SQL Server elavult Microsoft OLE DB-illesztőprogramját (SQLNCLI11) az SQL Server adatforrás-definícióiban az SQL Server .NET-keretrendszer adatszolgáltatójára.
Az alábbi táblázat bemutat egy példát a .NET-keretrendszer SQL Server-adatszolgáltatójának a kapcsolati sztringjére, amely lecseréli az SQL Server OLE DB-illesztőprogramjának megfelelő kapcsolati sztringet.
| OLE DB-illesztő az SQL Serverhez | .NET-keretrendszer SQL Server adatszolgáltatója |
|---|---|
Provider=SQLNCLI11;Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW;Trusted_Connection=yes; |
Data Source=sqldb.database.windows.net;Initial Catalog=AdventureWorksDW2016;Integrated Security=SSPI;Encrypt=true;TrustServerCertificate=false |
Partícióforrások keresztellenőrzése
Ahogy több adatforrástípus is létezik, a táblázatos modellek több partícióforrás-típust is tartalmazhatnak az adatok táblázatba való importálásához. A partíciók lekérdezési partícióforrást vagy M partícióforrást is használhatnak. Ezek a partícióforrás-típusok viszont hivatkozhatnak szolgáltatói adatforrásokra vagy strukturált adatforrásokra. Bár az Azure Analysis Services táblázatos modelljei támogatják a különböző adatforrás- és partíciótípusok kereszthivatkozását, a Power BI szigorúbb kapcsolatot kényszerít ki. A lekérdezési partícióforrásoknak szolgáltatói adatforrásra kell hivatkozniük, az M partícióforrásnak pedig strukturált adatforrásra kell hivatkoznia. Más kombinációk nem támogatottak a Power BI-ban. Ha kereszthivatkozású szemantikai modellt szeretne migrálni, az alábbi táblázat a támogatott konfigurációkat ismerteti:
| Adatforrás | Partícióforrás | Megjegyzések | XMLA-végponttal támogatott |
|---|---|---|---|
| Szolgáltató adatforrása | Partícióforrás lekérdezése | Az AS motorja a patronalapú kapcsolati stacket használja az adatforrás eléréséhez. | Igen |
| Szolgáltató adatforrása | M partíció forrása | Az AS-motor lefordítja a szolgáltatói adatforrást egy általános strukturált adatforrásra, majd a Mashup motor használatával importálja az adatokat. | Nem |
| Strukturált adatforrás | Partícióforrás lekérdezése | Az AS-motor a partícióforrás natív lekérdezését egy M kifejezésbe burkolja, majd a Mashup motor használatával importálja az adatokat. | Nem |
| Strukturált adatforrás | M partícióforrás | Az AS motor a Mashup motorral importálja az adatokat. | Igen |
Adatforrások és megszemélyesítés
A szolgáltatói adatforrásokhoz definiálható megszemélyesítési beállítások nem relevánsak a Power BI-ban. A Power BI egy másik, szemantikai modellbeállításokon alapuló mechanizmust használ az adatforrás hitelesítő adatainak kezeléséhez. Ezért győződjön meg arról, hogy szolgáltatói adatforrás létrehozásakor a szolgáltatásfiókot választja.
Részletes feldolgozás
Ha ütemezett vagy igény szerinti frissítést indít el a Power BI-ban, a Power BI általában a teljes szemantikai modellt frissíti. Sok esetben hatékonyabb a frissítések szelektívebb végrehajtása. Részletes feldolgozási feladatokat végezhet az SQL Server Management Studióban (SSMS) az alább látható módon, vagy külső eszközök vagy szkriptek használatával.
A TMSL-frissítési parancs felülírásai
A Frissítés parancs (TMSL) felülbírálásai lehetővé teszik, hogy a felhasználók a frissítési művelethez másik partíció lekérdezésdefiníciót vagy adatforrás-definíciót válasszanak.
E-mail-előfizetések
Az XMLA-végponttal frissített szemantikai modellek nem aktiválnak e-mail-előfizetést.
Hibák a Prémium szintű kapacitással kapcsolatban
Kapcsolódás kiszolgálóhoz hiba az SSMS-ben
Ha power BI-munkaterülethez csatlakozik az SQL Server Management Studióval (SSMS), a következő hiba jelenhet meg:
TITLE: Connect to Server
------------------------------
Cannot connect to powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].
------------------------------
ADDITIONAL INFORMATION:
The remote server returned an error: (400) Bad Request.
Technical Details:
RootActivityId:
Date (UTC): 10/6/2021 1:03:25 AM (Microsoft.AnalysisServices.AdomdClient)
------------------------------
The remote server returned an error: (400) Bad Request. (System)
Ha SSMS-sel csatlakozik Egy Power BI-munkaterülethez, győződjön meg a következőkről:
- Az XMLA-végpont beállítása engedélyezve van a bérlő kapacitásához. További információt az XMLA írás-olvasás engedélyezése című témakörben talál.
- Az XMLA-végpontok engedélyezése és az Elemzés az Excelben helyszíni szemantikai modellek beállításával engedélyezve van a bérlői beállításokban.
- Az SSMS legújabb verzióját használja. Töltse le a legújabbat.
Lekérdezés végrehajtása az SSMS-ben
Ha power BI Premium- vagy Power BI Embedded-kapacitásban lévő munkaterülethez csatlakozik, az SQL Server Management Studio a következő hibát jelenítheti meg:
Executing the query ...
Error -1052311437: We had to move the session with ID '<Session ID>' to another Power BI Premium node. Moving the session temporarily interrupted this trace - tracing will resume automatically as soon as the session has been fully moved to the new node.
Ez egy tájékoztató üzenet, amely figyelmen kívül hagyható az SSMS 18.8 és újabb verzióiban, mert az ügyfélkódtárak automatikusan újracsatlakoznak. Vegye figyelembe, hogy az SSMS 18.7.1-s vagy újabb verziójával telepített ügyfélkódtárak nem támogatják a munkamenet-nyomkövetést. Töltse le a legújabb SSMS-t.
Nagy parancs végrehajtása az XMLA-végponttal
Ha nagy parancsot hajt végre az XMLA-végponttal, a következő hibaüzenet jelenhet meg:
Executing the query ...
Error -1052311437:
The remote server returned an error: (400) Bad Request.
Technical Details:
RootActivityId: 3716c0f7-3d01-4595-8061-e6b2bd9f3428
Date (UTC): 11/13/2020 7:57:16 PM
Run complete
Ha az SSMS 18.7.1-s vagy újabb verziójával hosszú ideig futó (>1 perces) frissítési műveletet hajt végre egy szemantikai modellen a Power BI Premium vagy a Power BI Embedded-kapacitásban , az SSMS akkor is megjelenítheti ezt a hibát, ha a frissítési művelet sikeres. Ennek oka az ügyfélkódtárak ismert hibája, amely miatt a frissítési kérelem állapota helytelenül van nyomon követve. Ez az SSMS 18.8-s és újabb verzióiban oldható fel. Töltse le a legújabb SSMS-t.
Ez a hiba akkor is előfordulhat, ha egy igen nagy kérés egy másik csomópontra van átirányítva a Prémium klászterben. Ez gyakran előfordul, amikor egy szemantikai modellt próbál létrehozni vagy módosítani egy nagy TMSL-szkripttel. Ilyen esetekben a hiba általában elkerülhető, ha a parancs végrehajtása előtt megadja az eredeti katalógust az adatbázis nevére.
Új adatbázis létrehozásakor létrehozhat egy üres szemantikai modellt, például:
{
"create": {
"database": {
"name": "DatabaseName"
}
}
}
Az új szemantikai modell létrehozása után adja meg a kezdeti katalógust, majd módosítsa a szemantikai modellt.
Egyéb ügyfélalkalmazások és -eszközök
Az olyan ügyfélalkalmazások és eszközök, mint az Excel, a Power BI Desktop, az SSMS vagy a Szemantikai modellekhez csatlakozó és azokkal együttműködő külső eszközök a Power BI Premium-kapacitásokban a következő hibát okozhatják: A távoli kiszolgáló hibát adott vissza: (400) Hibás kérés.. A hiba különösen akkor fordulhat elő, ha egy mögöttes DAX-lekérdezés vagy XMLA-parancs hosszú ideig fut. A lehetséges hibák elkerülése érdekében mindenképpen használja az Analysis Services-ügyfélkódtárak legújabb verzióit telepítő legújabb alkalmazásokat és eszközöket rendszeres frissítésekkel. Alkalmazástól vagy eszköztől függetlenül a prémium szintű kapacitásban lévő szemantikai modellekhez való csatlakozáshoz és az XMLA-végponton keresztüli munkához minimálisan szükséges ügyfélkódtár-verziók a következők:
| Ügyfélkönyvtár | Verzió |
|---|---|
| MSOLAP | 15.1.65.22 |
| AMO | 19.12.7.0 |
| ADOMD | 19.12.7.0 |
Szerepkör-tagságok szerkesztése az SSMS-ben
Ha az SQL Server Management Studio (SSMS) v18.8 használatával szerkeszt egy szerepkör-tagságot egy szemantikai modellen, az SSMS a következő hibát jelenítheti meg:
Failed to save modifications to the server.
Error returned: ‘Metadata change of current operation cannot be resolved, please check the command or try again later.’
Ennek oka az App Services REST API-jának ismert hibája. Ezt egy közelgő kiadásban oldjuk meg. Addig is, a hiba megkerüléséhez a Szerepkör tulajdonságai területen kattintson a Szkript gombra, majd írja be és hajtsa végre a következő TMSL-parancsot:
{
"createOrReplace": {
"object": {
"database": "AdventureWorks",
"role": "Role"
},
"role": {
"name": "Role",
"modelPermission": "read",
"members": [
{
"memberName": "xxxx",
"identityProvider": "AzureAD"
},
{
"memberName": “xxxx”
"identityProvider": "AzureAD"
}
]
}
}
}
Közzétételi hiba – Csatlakoztatott élő szemantikai modell
Amikor újra közzétesz egy élő csatlakoztatott szemantikai modellt az Analysis Services-összekötő használatával, a következő hibaüzenet jelenik meg: "Létezik egy meglévő jelentés-/szemantikai modell ugyanazzal a névvel. Törölje vagy nevezze át a meglévő szemantikai modellt, és próbálkozzon újra." jelenhet meg.
Ennek az az oka, hogy a közzétett szemantikai modell más kapcsolati sztringgel rendelkezik, és ugyanaz a neve, mint a meglévő szemantikai modellnek. A probléma megoldásához törölje vagy nevezze át a meglévő szemantikai modellt. Mindenképpen tegye közzé újra a jelentéstől függő alkalmazásokat. Szükség esetén az alsóbb rétegbeli felhasználókat tájékoztatni kell arról, hogy frissítsenek minden könyvjelzőt az új jelentés címével, hogy hozzáférjenek a legújabb jelentéshez.
Élő kapcsolatú szemantikai modell nem tölthető be
A Power BI Desktop 2024. márciusi vagy újabb verzióival új élő csatlakoztatott modellt létrehozni vagy megnyitni próbáló felhasználók a következőhöz hasonló hibát tapasztalhatnak: "Nem sikerült csatlakozni a modellhez a Power BI szolgáltatás. Előfordulhat, hogy az adatkészletet törölték, átnevezték, áthelyezték, vagy lehetséges, hogy nincs engedélye a hozzáférésre."
A hiba akkor fordulhat elő, ha a felhasználó környezetében proxy van konfigurálva, és a proxy megakadályozza a Power BI szolgáltatás való hozzáférést. A Power BI Desktop 2024. márciusi verziójától kezdve a felhasználó környezetének engedélyeznie kell a *.pbidedicated.windows.net végponton lévő Power BI szolgáltatás vagy a szuverén felhők megfelelő Power BI szolgáltatás végpontjaihoz való kapcsolódást.
Annak ellenőrzéséhez, hogy a probléma proxybeállítások eredménye-e, próbálja ki az SQL Server Analysis Services-összekötőt a Power BI Desktopban, vagy bármely külső vagy külső eszközt, például az SQL Server Management Studiót, hogy bármilyen prémium szintű munkaterülethez csatlakozzon.
Az általános XML/A-kapcsolatok tesztelésével kapcsolatos további információkért tekintse meg a jelen cikk ügyfélkapcsolati szakaszát.
Az Excel-munkafüzet nem nyitható meg
Előfordulhat, hogy az Excel-munkafüzet nem nyitható meg a következő hibaüzenettel: "Az adatforrás inicializálása nem sikerült. Ellenőrizze az adatbázis-kiszolgálót, vagy forduljon az adatbázis rendszergazdájához." Ha a munkafüzet kapcsolatot tartalmaz egy Power BI szemantikai modellel, ellenőrizze, hogy a kapcsolati sztring tartalmazza-e a "Catalog Rebound=True" tulajdonságot. Ha a tulajdonság megtalálható, távolítsa el, mentse a munkafüzetet, és próbálja meg újból megnyitni.
A "Catalog Rebound=True" tulajdonságot az Analysis Services OLE DB Provider (MSOLAP) automatikusan hozzáadja az Excel újabb verzióiban, amikor a Power BI szemantikai modellhez való kapcsolódást a szolgáltató optimalizálja. Mivel a tulajdonság megmarad a munkafüzetben, ha ugyanazt a munkafüzetet nyitja meg az Excelben, amely az optimalizálást nem támogató szolgáltató régebbi verzióját használja, az Excel nem fogja megnyitni a munkafüzetet.
A "Catalog Rebound" csak belső használatra készült.
Munkaterület/kiszolgáló aliasa
Az Azure Analysis Servicestől eltérően a prémium szintű munkaterületeken a kiszolgálónév-aliasok nem támogatottak.
FEDEZZE_FEL_M_KIFEJEZÉSEK
A DMV DISCOVER_M_EXPRESSIONS adatkezelési nézet (DMV) jelenleg nem támogatott a Power BI-ban az XMLA-végpont használatával. Az alkalmazások a táblázatos objektummodell (TOM) használatával szerezhetik be az adatmodell által használt M-kifejezéseket.
A Premiumban az erőforrás-kezelés parancs memóriakorlátja
A prémium kapacitások erőforrás-szabályozással biztosítják, hogy egyetlen szemantikai modellművelet sem haladhatja meg a kapacitás rendelkezésre álló memóriaerőforrásainak mennyiségét – amelyet a termékváltozat határoz meg. Egy P1-előfizetés például 25 GB-os elemenként érvényes memóriakorlátot, P2-előfizetés esetén a korlát 50 GB, P3-előfizetés esetén pedig 100 GB. A szemantikai modell (adatbázis) mérete mellett az érvényes memóriakorlát az alapul szolgáló szemantikai modell parancsműveletekre is vonatkozik, például a Létrehozásra, az Alterre és a Frissítésre.
A parancs tényleges memóriakorlátja a kapacitás memóriakorlátjának (amelyet a SKU határoz meg) vagy a DbpropMsmdRequestMemoryLimit XMLA tulajdonság értékének kisebbikén alapul.
P1-kapacitás esetén például a következő esetekben:
DbpropMsmdRequestMemoryLimit = 0 (vagy nem meghatározott), a parancs érvényes memóriakorlátja 25 GB.
DbpropMsmdRequestMemoryLimit = 5 GB, a parancs érvényes memóriakorlátja 5 GB.
DbpropMsmdRequestMemoryLimit = 50 GB, a parancs érvényes memóriakorlátja 25 GB.
A parancsok tényleges memóriakorlátját általában a szemantikai modell számára engedélyezett memória alapján számítja ki a kapacitás (25 GB, 50 GB, 100 GB), és hogy a szemantikai modell mennyi memóriát használ már a parancs végrehajtásakor. Például egy P1-kapacitáson 12 GB-ot használó szemantikai modell lehetővé teszi egy 13 GB-os új parancs tényleges memóriakorlátját. Az érvényes memóriakorlátot azonban tovább korlátozhatja a DbPropMsmdRequestMemoryLimit XMLA tulajdonság, ha egy alkalmazás opcionálisan megadja. Ha az előző példában 10 GB van megadva a DbPropMsmdRequestMemoryLimit tulajdonságban, akkor a parancs érvényes korlátja tovább csökken 10 GB-ra.
Ha a parancsművelet a korlát által megengedettnél több memóriát próbál felhasználni, a művelet meghiúsulhat, és a rendszer hibát ad vissza. Az alábbi hiba például azt írja le, hogy a rendszer túllépte a 25 GB-os (P1 kapacitású) tényleges memóriakorlátot, mert a szemantikai modell már 12 GB-ot (12288 MB) használt fel a parancs végrehajtásakor, és a parancsműveletre 13 GB (13312 MB) érvényes korlátot alkalmaztak:
"Erőforrás-szabályozás: Ezt a műveletet megszakították, mert nem volt elég memória a futtatásához. Növelje a prémium szintű kapacitás memóriáját, ahol ez a szemantikai modell üzemel, vagy csökkentse a szemantikai modell memóriaigényét az importált adatok mennyiségének korlátozásával. További részletek: felhasznált memória 13312 MB, memóriakorlát 13312 MB, adatbázis mérete a parancs végrehajtása előtt 12288 MB. További információ: https://go.microsoft.com/fwlink/?linkid=2159753."
Bizonyos esetekben, ahogy az alábbi hiba is mutatja, a "felhasznált memória" 0, de az "adatbázis mérete a parancs végrehajtása előtt" már nagyobb, mint a tényleges memóriakorlát. Ez azt jelenti, hogy a művelet nem tudta megkezdeni a végrehajtást, mert a szemantikai modell által már felhasznált memória mennyisége nagyobb, mint a termékváltozat memóriakorlátja.
"Erőforrás-szabályozás: Ezt a műveletet megszakították, mert nem volt elég memória a futtatásához. Növelje a prémium szintű kapacitás memóriáját, ahol ez a szemantikai modell üzemel, vagy csökkentse a szemantikai modell memóriaigényét az importált adatok mennyiségének korlátozásával. További részletek: felhasznált memória 0 MB, memóriakorlát 25600 MB, adatbázis mérete a parancs végrehajtása előtt 26000 MB. További információ: https://go.microsoft.com/fwlink/?linkid=2159753."
A tényleges memóriakorlát túllépésének elkerülése érdekében:
- Frissítsen egy nagyobb Premium kapacitási méretre (SKU) a szemantikai modell számára.
- Csökkentse a szemantikai modell memóriaigényét az egyes frissítésekbe betöltött adatok mennyiségének korlátozásával.
- Az XMLA-végponton keresztüli frissítési műveletek esetében csökkentse a párhuzamosan feldolgozott partíciók számát. Ha túl sok partíciót dolgoznak fel párhuzamosan egyetlen paranccsal, az meghaladhatja az érvényes memóriakorlátot.