A Microsoft OLE DB Driver for SQL Server hibaelhárítása

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsSQL-adatbázis a Microsoft Fabricben

Használja ezt a cikket az OLE DB művelet meghibásodott szakaszának azonosítására, kiválasztani a következő ellenőrzést, és részletes hibakeresési utasításokat találni. Az útmutatás a jelenlegi szolgáltatót használja, MSOLEDBSQL19. A kiadás-specifikus hibákért és frissítési változásokért lásd: Ismert problémák és főbb verzióbeli különbségek.

Azonosítsd a tünetet

Rögzítse a teljes hibaleírást és az összes elérhető hibarekordot a beállítások megváltoztatása előtt. Egy felső szintű HRESULT, mint DB_E_ERRORSOCCURREDpéldául , önmagában nem azonosítja az okot. Jegyezd fel, hogy a hiba a szolgáltató betöltésekor, kapcsolat megnyitása, parancs végrehajtása, adat lekérése vagy tranzakció elvégzése során történik-e.

Jelenség Kezdje itt
A szolgáltató nem található, vagy az osztály nincs regisztrálva. Szolgáltató regisztráció és architektúra
A bejelentkezés meghibás, a hozzáférés megtagadódik, vagy az integrált hitelesítés meghibás. Bejelentkezési és hitelesítési hibák
A tanúsítványlánc nem megbízható, vagy a tanúsítvány neve nem egyezik. TLS tanúsítvány hibái
Szerver vagy instance nem található, vagy a kapcsolatot elutasítják. Hálózati és példány felfedezési hibák
A paraméterek meghibásodnak, az értékek levágódnak, vagy az adatokat nem lehet átalakítani. Paraméter- és adatátalakítási hibák
A kapcsolat megszakad, a helyreállítás meghibás, vagy lejár az időkorlát. Kapcsolatvesztés és időkorlátok
Hiányoznak hibaadatok, vagy szükséged van trace-re a támogatáshoz. Diagnosztika és követés

Kapcsolati hibák esetén hasonlítsuk össze az alkalmazást egy Universal Data Link (UDL) kapcsolatteszttel. Ugyanazt a számítógépet, szolgáltatót, folyamatarchitektúrát, hitelesítési identitást, szervert, adatbázist és titkosítási beállításokat használjuk. Egy sikeres teszt egy másik szolgáltatóval vagy identitással nem bizonyítja, hogy az alkalmazás konfigurációja működik.

Szolgáltató regisztráció és architektúra

Az olyan hibák, mint a Provider cannot be found vagy a REGDB_E_CLASSNOTREG (0x80040154, Class not registered) arra utalnak, hogy a szolgáltató betöltése az SQL Server-hitelesítés előtt történik.

  1. Ellenőrizd azt a szolgáltatót, akit a kérelem kér. MSOLEDBSQL19 és MSOLEDBSQL különböző főbb változatokat azonosíthat. A jelenlegi illesztőprogram telepítése nem változtatja meg az alkalmazás szolgáltatóválasztását. Ha az alkalmazás még mindig más szolgáltatót kér, kövesse a migrációs lépéseket .
  2. Ellenőrizd az alkalmazást üzemeltető folyamat architektúráját. Egy 32 bites alkalmazásnak szüksége van a 32 bites szolgáltatóra, még 64 bites Windows-on is. Szolgáltatás vagy ütemezett feladat esetén nézd meg a futtatható fájlt és a fiókot, amit az adott szerver használ, ne csak a fejlesztői környezetedet.
  3. Telepítse vagy javítsa meg az illesztőprogramot a támogatott telepítővel azon a számítógépen, amely az alkalmazást futtatja. Az x64 telepítő mind 64 bites, mind 32 bites illesztőprogram-bináriákat tartalmaz. Ellenőrizd a szükséges függőségeket az OLE DB Driver telepítése és a Rendszer követelményei között. Ne másolj egy másik számítógépről az illezőprogramkönyvtárakat a telepítés helyett.
  4. Ismételd meg az UDL tesztet a megfelelő architektúrával és szolgáltatóval. Ha működik, de az alkalmazás még mindig nem tudja betölteni a szolgáltatót, hasonlítsd össze az alkalmazás hatékony szolgáltatóválasztását és hostarchitektúráját a teszttel.

Ha a hibaüzenetben kifejezetten a(z) adal.dll szerepel, ellenőrizd inkább a hitelesítési könyvtár ismert problémáját, ahelyett hogy hiányzó SQL Server-szolgáltatóként kezelnéd.

Bejelentkezési és hitelesítési hibák

Különbséget kell tennie a szerver bejelentkezés elutasítását a hitelesítés megszerzésének vagy titkosított kapcsolat létrehozásának sikertelenségétől. Olvassa el a teljes hibaszöveget, beleértve az összes beépített szolgáltató hibát is.

  1. Az SQL Server 18456-os hiba esetén kérd meg az adatbázis-adminisztrátort, hogy ellenőrizze a megfelelő szerverhibanapló bejegyzést és állapotot. Ellenőrizd az autentifikációs módot, bejelentkezési állapotot, a kért adatbázist és az adatbázis-hozzáférést MSSQLSERVER_18456 segítségével. Ne feltételezd, hogy minden bejelentkezés elutasítása hibás jelszót jelent.
  2. Integrált hitelesítéshez igazoljuk az alkalmazás futó azonosítóját. Egy szolgáltatási vagy ütemezett feladat fiók eltérhet attól a felhasználótól, aki sikeresen tesztelte a kapcsolatot. Ha az üzenet tartalmazza: Nem lehet SSPI kontextust generálni, kövesse a Security Support Provider Interface (SSPI) hibakeresést és a Service Principal Name (SPN) támogatást.
  3. Microsoft Entra ID esetén ellenőrizd, hogy a kiválasztott hitelesítési módszer illeszkedik-e az alkalmazás végrehajtási környezetéhez, és hogy az identitása hozzáférjen a cél adatbázishoz. Tekintse át a metódus-specifikus beállításokat és hozzáférési token korlátozásokat a Use Microsoft Entra ID oldalon. Ne kombinálj egy hozzáférési tokent ellentmondó hitelesítéssel vagy jogosultsági tulajdonságokkal.
  4. Hasonlítsd össze az effektív beállításokat a megfelelő kapcsolati karakterlánc kulcsszótáblával. IDBInitialize::Initialize, IDataInitialize::GetDataSource, és az ActiveX Data Objects (ADO) különböző kulcsszótáblákat használnak. Nézd meg a táblázatot, hogy melyik felületet használja az alkalmazásod.

A szöveg A cél fő neve hibás különböző kontextusokban is megjelenhet. Ha ezt a Nem hozható létre SSPI-környezet üzenet kíséri, vizsgáld meg a Windows-hitelesítést és az SPN-eket. Ha a hiba azonosítja a tanúsítványt vagy a titkosítás kézfogását, használja a következő szakaszt.

TLS tanúsítvány hibái

A Transport Layer Security (TLS) hibák még azelőtt előfordulhatnak, hogy a bejelentkezés eléri az SQL Server-t. A jelenlegi illesztőprogram alapértelmezés szerint kötelező titkosítást engedélyez, így egy frissítés feltárhat egy tanúsítvány bizalmi vagy névproblémát, amit egy régebbi kapcsolati konfiguráció nem észlelt.

  1. A tanúsítványláncot egy nem megbízható hatóság adta ki, ellenőrizze az SQL Server által bemutatott tanúsítványt és a kiadó tanúsítványláncot, amelyet az ügyfél számítógép megbíz. Konfiguráljon egy érvényes szervertanúsítványt, és telepítse a szükséges megbízható gyökér- és köztes tanúsítványokat a szervezete tanúsítványkezelési folyamatán keresztül.
  2. Tanúsítványnév eltérése esetén hasonlítsuk össze az alkalmazás által használt szerver vagy hallgató nevét a tanúsítvány neveivel. Használj olyan tanúsítványt, amely lefedi a tervezett kapcsolat nevét. Ha az alkalmazás szándékosan más kapcsolatnevet használ, tekintse át a dokumentált HostNameInCertificate tulajdonságot , mielőtt konfigurálná a várható tanúsítvány nevet.
  3. Ellenőrizd a hatékony titkosítási és érvényesítési beállításokat, beleértve a regisztrációs beállításokat is. Tekintse át a titkosítási és tanúsítvány ellenőrző tábláit az elsőbbségi és Strict viselkedés szempontjából. Üzemmódban Strict az illesztőprogram érvényesíti a tanúsítványt függetlenül a trust-server-certificate beállítástól.
  4. Ha a hiba migráció közben kezdődött, ellenőrizd a fő verzió hibaelhárítását, beleértve a titkosítási tulajdonság értéktípusát és a külső Strict mód használatának ServerCertificate korlátozását.

Használd az SQL Server tanúsítvány követelményeit és a Certificate lánc nem megbízható hibakeresést részletes ellenőrzésekhez. Tartsd a titkosítást és a tanúsítvány validálását engedélyezve a gyártásban. Bármelyik kikapcsolása nem javítja meg a tanúsítvány telepítési problémáját.

Hálózati és példány felfedezési hibák

A szerver nem található, a hiba történt a megadott szerver/példány megkeresésekor vagy kapcsolatelutasítási hibák esetén azonosítsa azt a végpontot, amelyet az alkalmazás elérni próbál.

  1. Ellenőrizd a szerver nevét, a példány nevét és a konfigurált figyelőportot az adatbázis-rendszergazdával. Győződjön meg róla, hogy az adatbázis szolgáltatás fut, és hogy a tervezett protokoll és a hallgató engedélyezve van. Ne feltételezd, hogy minden példány a 1433-as porton hallgat.
  2. Távoli Átvitelvezérlési Protokoll (TCP) kapcsolathoz teszteljük az ismert végpontot a tcp:<server>,<port> meghajtó szervernév formátumával. Tartsd meg ugyanazokat az autentifikációi, adatbázis- és titkosítási beállításokat. Lásd a(z) kapcsolatikarakterlánc-kulcsszavak című témakört az interfészére vonatkozó kiszolgálókulcsszóval kapcsolatban.
  3. Ha az explicit host és port működik, de a megnevezett példány nem, vizsgáld meg az SQL Server böngészőt és a példányok felderítését. Ellenőrizze a Browser szolgáltatást, valamint a User Datagram Protocol (UDP) 1434-es portjához vezető útvonalat ott, ahol Browser-felderítést használnak.
  4. Ha a kifejezetten megadott végpont sem működik, ellenőrizd a DNS-feloldást, az útválasztást, valamint az alkalmazást futtató gazdagépről annak a portnak a tűzfal általi elérhetőségét, amelyen a szolgáltatás ténylegesen figyel. Kövesse a hálózathoz kapcsolódó vagy instance-specifikus kapcsolati hibákat , ahelyett, hogy egyszerre több kapcsolati beállítást változtatnál.

Elérhetőségi csoportos hallgatóként érdemes áttekinteni a magas rendelkezésre állást és katasztrófa-helyreállítási támogatást is. A LocalDB esetében a LocalDB támogatást használd a helyi példány és a felhasználói kontextus ellenőrzésére a távoli TCP felfedezési lépések helyett.

Paraméter- és adatátalakítási hibák

Ha a kapcsolat megnyílik, de parancs végrehajtása vagy adatkeresés meghiúsul, csökkentsd a reprodukálást a hibás parancsra és értékre. Őrizze meg az eredeti adattípust, hosszt, null státuszt és karakterkódolást az érzékeny adatok cseréjekor.

  1. Hasonlítsuk össze minden ? paraméterjelölőt a kötési ordinaljával, irányával és metaadataival. Amikor használod ICommandWithParameters::SetParameterInfo, az SQL forráskód típusát a parancshoz vagy tárolt eljáráshoz igazítsuk. Ne feltételezd, hogy a paraméter metaadat mindig automatikusan származik. Tekintse át a parancsparamétereket a levezetési korlátozások és a kimenet-paraméter viselkedése szempontjából.
  2. Vizsgáld meg az accessor kötési státuszokat és az egyes visszaadott értékek státuszát és hosszát, nem csak az összértéket HRESULT. Tulajdonságbeállítási hibák esetén ellenőrizze az egyes tulajdonságok dwStatus-ját. Egy részleges siker visszajelzés, DB_S_ERRORSOCCURRED például állapot-tömb vizsgálatot igényelhet, még akkor is, ha nincs hibaobjektum. Lásd a Visszaküldési kódokat.
  3. Átalakításhoz vagy vágáshoz hasonlítsuk össze a fogyasztói puffer típusát és méretét a tényleges oszlop- vagy paramétermetaadatokkal. Ellenőrizze a numerikus értékek pontosságát és skáláját, a dátum-/időértékek érvényes tartományait és törtmásodperceit, valamint a karakterpufferek bájtban megadott hosszát. Vizsgáld DBSTATUS_E_CANTCONVERTVALUEmeg, és ne DBSTATUS_S_TRUNCATED kezeld teljes értékként. Használj adattípus-leképezést, sorok lekérését, valamint dátum- és időátalakításokat a releváns szabályokhoz.
  4. Ha a kötött kimeneti paraméterek hiányoznak, kimerítsd a visszaküldött sorhalmazokat, mielőtt elolvasod őket. Kövesse az IMultipleResults használatát több eredményhalmaz feldolgozásához. Streamelt kimeneti paraméterek esetén a következő eredmény lekérése előtt dolgozza fel vagy zárja le a függőben lévő streameket, a A kimeneti paraméterek streamingtámogatása című részben leírtak szerint.

Az ADO-specifikus hozzárendelések esetén tekintse át a(z) Use ADO with the OLE DB Driver című témakört, valamint a Use Microsoft Entra ID című témakörben a(z) DataTypeCompatibility vonatkozó hitelesítési korlátozásokat. Ne adj hozzá kompatibilitási beállítást anélkül, hogy mindkettőt ellenőriznéd.

Ha egy sql_variant oszlopban egy illesztőprogram-frissítés után sérült szűk karakterláncok találhatók, a tárolt adatok módosítása előtt tekintse át a meglévő SSVARIANT ismert problémájának ismertetését és helyreállítási eljárását.

Kapcsolatvesztés és időkorlátok

Jegyezd fel, mikor működött utoljára a kapcsolat, melyik művelet sikerült meg, és mennyi ideig futott az adott művelet. Ezeket az eseteket különböztetd meg, mielőtt újrapróbálkozás vagy időtúllépés beállításait változtatnád.

Bukás szakasz Ellenőrzések és részletes útmutatás
Kapcsolat megnyitása. Először ellenőrizd a szolgáltató, hálózat, hitelesítési és TLS hibákat. Ellenőrizd a hatékony DBPROP_INIT_TIMEOUT vagy a hozzá tartozó kapcsolati kulcsszót. Lásd: Kapcsolati időkorlát hibaelhárítás.
Parancs végrehajtása. Ellenőrizd a DBPROP_COMMANDTIMEOUT vagy az alkalmazás parancs-időkorlátjának beállítását. Vizsgáld meg a blokkolást és lekérdezési teljesítményt a lekérdezés időtúlolás hibakeresésével. A kapcsolati időtúllépés növelése nem változtatja meg a parancs időtúllépését.
Újrahasználva egy üres kapcsolatot. Ellenőrizze a helyreállítási feltételeket, újrapróbálkozási beállításokat és a várható hibákat az Idle connection resiliency-ben. A helyreállítás sikertelen lehet, amikor a parancs időkorlátja lejár, mielőtt az újracsatlakozás befejeződne.
A kapcsolat megszakadása a végrehajtás vagy a véglegesítés közben. Vesd össze a kliens- és szervereseményeket annak ellenőrzéséhez, hogy történt-e hálózati kimaradás, szerver-újraindítás vagy feladatátvétel. Állapítsd meg a művelet eredményét, mielőtt eldöntenéd, biztonságos-e újra próbálkozni.

Az inaktív kapcsolatokkal szembeni rugalmasság nem biztosítja a kezdeti kapcsolódás újrapróbálását, illetve tetszőleges parancsok és tranzakciók automatikus újrajátszását. Megerősített átmeneti hiba esetén használj korlátozott alkalmazási újrapróbálkozásokat késleltetéssel, és naplózza minden próbálkozást. Ne próbálkozzon ismételten a szolgáltató betöltésével kapcsolatos hibák, az elutasított hitelesítési adatok vagy a tanúsítvány-ellenőrzési hibák esetén anélkül, hogy elhárítaná az okot.

Figyelmeztetés

Ha egy kapcsolat megszakad írás vagy commit során, az ügyfél nem biztos, hogy nem tudja, hogy az SQL Server kötelezte-e el a tranzakciót. Ne játssza újra vakon a műveletet. Ellenőrizd az eredményét, vagy használj olyan alkalmazástervt, amely megakadályozza a duplikált effekteket, mielőtt újra próbálkozna.

Diagnosztika és követés

Gyűjtse össze a diagnosztikai adatokat a hiba bekövetkezésekor, mielőtt a nem kapcsolódó szolgáltatói hívások felülírnák a hibainformációkat.

  1. Rögzítsd a sikertelen műveletet, időbélyeget és időzónát, az eltelt időt, és HRESULT. A natív OLE DB-kliensek esetében az összes elérhető rekordot a IErrorInfo és a IErrorRecords segítségével kérje le, ne csak az első leírást. Adja meg a(z) SQLSTATE és az SQL Server natív hibaszámát, ha az a(z) ISQLErrorInfo révén elérhető. Lásd a hibainformációk lekérését és az SQL Server hibarészleteit. ADO esetén gyűjtsd be a kapcsolat Errors gyűjteményét.
  2. Gyűjtsd össze a tulajdonságonkénti, kötésenkénti és értékenkénti állapotokat az olyan metódusokhoz, amelyek így jelzik a hibákat. Egy hiányzó hibaobjektum nem teszi biztonságossá a részleges siker eredményét figyelmen kívül hagyni.
  3. Kapcsold össze a kliens hibáját a szerver hibanaplójával vagy az Extended Events-szel. Ha elérhető, jegyezd ClientConnectionID fel és ActivityID. A prelogin előtt meghibásodás előfordulhat kliens kapcsolatazonosító nélkül.
  4. Ha hibarekordok nem elegendőek, használd az Extended Events naplóban a Access diagnosztikai adatokat a driver követéshez és korreláció beállításához. Gyűjts egy korlátos nyomot a reprodukció körül, és hagyd abba a követést utána.

Amikor eszkalálod, add fel az illesztőprogram verziót, a kért szolgáltatót, az alkalmazás- és folyamatarchitektúrát, a szerververziót, hitelesítési módszert, hatékony kapcsolati beállításokat, hibaszakaszt, hibaadatokat és minimális reprodukciót. Add meg, hogy a megfelelő UDL-teszt sikeres-e, és hogy a probléma egy vagy több gazdagépet érint.

Töröld a jelszavakat, hozzáférési tokeneket és egyéb titkokat a kapcsolati beállításokból és naplókból. Nézd át a lekérdezési szöveg és érzékeny adatok nyomait, tárold őket korlátozott hozzáféréssel, és csak egy jóváhagyott támogató csatornán keresztül oszd meg.

Kapcsolódó tartalom

  • Last updated on