Datubāzu savienojumu pārskats¶

Satura rādītājs¶

1. Kā darbojas savienojumi
2. Tehnoloģiju ceļveži
3. Priekšnosacījums: instalēt ODBC draiveri digna resursdatorā
4. Izveidot datubāzes savienojumu
5. ODBC rekvizīti
6. Rekvizītu vērtību šifrēšana
7. Savienojuma testēšana
8. Kuru datubāzi redz savienojums
9. Profilēšanas režīms un darba shēma
10. DSN izmantošana
11. Problēmu novēršana

Kā darbojas savienojumi¶

digna sasniedz katru avota tehnoloģiju caur ODBC. Savienojums ir ODBC rekvizītu saraksts, ko ievadāt kā atslēgas/vērtības pārus. Kad digna atver savienojumu, tā apvieno šos pārus savienojuma virknē — Key=Value, atdalītus ar ;, tādā secībā, kādā tos norādījāt — un nodod to ODBC draiveru pārvaldniekam digna resursdatorā.

Tas, ka rekvizītus ievadāt paši, padara iestatīšanu bez DSN (DSN-less): savienojums satur visu, kas draiverim nepieciešams, tāpēc resursdatorā nav jāreģistrē ODBC datu avots (DSN). Šis ir ieteicamais veids, kā konfigurēt digna, jo savienojuma definīcija pilnībā atrodas digna un pārvietojas kopā ar to.

Kāpēc ODBC¶

Iepriekšējos izlaidumos varēja izvēlēties starp tehnoloģijai specifisku draiveri un ODBC, izmantojot slēdzi Use ODBC. Sākot ar Release 2026.06, digna balstās tikai uz ODBC. Viena standarta saskarne sniedz vairāk nekā atsevišķu pielāgotu draiveru kopa:

• Autentifikācija — autentifikācija ir daļa no ODBC, tāpēc savienojums var izmantot visu, ko atbalsta tā draiveris: paroles, tokenus un PAT, Kerberos un Active Directory, MFA un pārlūkā balstītu vienreizējo pieteikšanos, mākoņa identitāti, klienta sertifikātus un TLS. Jaunas metodes kļūst pieejamas ar draivera atjauninājumu, negaidot digna izlaidumu.
• Draiveri, ko uztur datubāzu piegādātāji — piegādātāja paša draiveris seko jaunām servera versijām un drošības labojumiem, un jūs varat to atjaunināt pēc sava grafika, neatkarīgi no digna.
• Viens veids, kā konfigurēt visu — katra tehnoloģija ir atslēgas/vērtības rekvizītu saraksts ar vienādu saskarni, vienādu sensitīvo vērtību šifrēšanu un vienādu problēmu novēršanu, nevis atšķirīgu lauku kopu katram avotam.
• Pielāgošana un aptvērums — draivera līmeņa opcijas, piemēram, taimauti, TLS iestatījumi, starpniekserveri un ielādes apjomi, ir pieejamas katram avotam, un var pievienot jebkuru tehnoloģiju ar atbilstošu ODBC draiveri, ieskaitot tādas, kurām digna nepublicē atsevišķu ceļvedi.

Tehnoloģiju ceļveži¶

Rekvizītu nosaukumi katram draiverim atšķiras, un katrai tehnoloģijai ir viena vai divas īpatnības, kuru citām nav. Tālāk norādītie ceļveži aptver šo daļu; šī lapa aptver digna pusi, kas visiem ir vienāda.

Priekšnosacījums: instalēt ODBC draiveri digna resursdatorā¶

digna atver avota savienojumus no servera, kurā darbojas digna backend, nevis no pārlūka. Tāpēc ODBC draiverim jābūt instalētam šajā datorā, un tā nosaukumam jābūt reģistrētam lokālajā draiveru pārvaldniekā.

odbcinst -q -d

odbcinst -q -d

Reģistrēta nosaukuma vietā visi izplatītie draiveru pārvaldnieki pieņem arī pilnu ceļu uz draivera bibliotēku, piemēram, Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. Tas noder, ja draiveris ir instalēts, bet nav reģistrēts.

Izveidot datubāzes savienojumu¶

Atveriet Admin Panel, dodieties uz cilni Database Connections un noklikšķiniet Add DB Connection. Ekrānā jānorāda pieci elementi:

Savienojums tiek administrēts centralizēti un pēc tam piešķirts vienam vai vairākiem projektiem, tāpēc viens un tas pats savienojums var apkalpot vairākus projektus.

ODBC rekvizīti¶

Katram rekvizītam noklikšķiniet Add Property un aizpildiet Key, Value un, slepenām vērtībām, izvēles rūtiņu Encrypted. Katras tehnoloģijas ceļvedī ir piemēra kopa šai tehnoloģijai, ko pielāgojat savai draivera versijai un serverim — skatiet piezīmi iepriekš.

Neatkarīgi no draivera rekvizītu kopa aptver tās pašas četras lietas:

• Driver — reģistrētais draivera nosaukums, kā aprakstīts iepriekš.
• Servera adrese — atslēga katram draiverim atšķiras: SERVER, HOST, DBCNAME, Server vai, Oracle gadījumā, DBQ savienojuma deskriptors.
• Akreditācijas dati — parasti UID un PWD; Snowflake izmanto UID kopā ar token, un Databricks izmanto burtisku lietotāju token kopā ar personīgās piekļuves tokenu laukā PWD.
• Datubāze vai katalogs, kurā strādāt, ja tehnoloģijai tāds ir — skatiet Kuru datubāzi redz savienojums.

Jebko citu, ko dokumentē draiveris, var pievienot tādā pašā veidā — savienojumu pūlu, soketu taimautus, Kerberos iestatījumus, starpniekservera iestatījumus. digna neinterpretē rekvizītus; tā tikai nodod tos tālāk.

Rekvizītu vērtību šifrēšana¶

Atzīmējiet Encrypted katram rekvizītam, kas satur noslēpumu — PWD, token, klienta slepeno atslēgu. Tad vērtība tiek šifrēta, pirms tā tiek saglabāta digna repozitorijā, ekrānā tā ir maskēta un tiek atšifrēta tikai tad, kad tiek veidota savienojuma virkne.

Rekvizītus, kas nav slepeni — draivera nosaukumu, resursdatoru, portu, datubāzi —, labāk atstāt nešifrētus, lai tie paliktu salasāmi ikvienam, kurš vēlāk uzturēs savienojumu.

Savienojuma testēšana¶

Dialogā Add DB Connection noklikšķiniet Test pirms saglabāšanas. Tests izmanto formā pašlaik esošās vērtības un veic reālu savienošanos, tāpēc tas ziņo tieši par to, ar ko saskartos inspekcija — nepareizu draivera nosaukumu, noraidītu paroli, nesasniedzamu resursdatoru. Nekas netiek saglabāts: testa savienojums tiek atritināts (rollback) neatkarīgi no tā, vai tas izdodas.

Esošam savienojumam novietojiet kursoru virs tā rindas cilnē Database Connections un noklikšķiniet uz kontaktdakšas ikonas, lai to pārbaudītu vēlreiz. Tas ir ātrākais veids, kā pārbaudīt, vai avots ir sasniedzams pēc paroles maiņas vai ugunsmūra izmaiņām.

Kuru datubāzi redz savienojums¶

Kad pievienojat datu avotu, digna piedāvā katalogus, shēmas un tabulas, ko savienojums var sasniegt. Cik tālu tas sniedzas, ir atkarīgs no tehnoloģijas:

Profilēšanas režīms un darba shēma¶

Profilēšanas režīms nosaka, kā digna apstrādā datus un aprēķina metrikas:

• Standard: Metrikas tiek aprēķinātas tieši avota tabulās, nekopējot datus.
• Permanent: Inspicētās dienas dati tiek nokopēti pastāvīgā tabulā, un metrikas tiek aprēķinātas nokopētajos datos.
• Session: Dati tiek nokopēti sesijas jeb pagaidu tabulā, un metrikas tiek aprēķinātas šajos pagaidu datos.

Režīms nosaka, kas savienojuma lietotājam jādrīkst darīt:

Standard tikai lasa, tāpēc tas ir režīms, kas jāizvēlas, ja digna piešķirta tikai lasīšanas piekļuve. Work Schema tiek nolasīta tikai režīmā Permanent, taču to tik un tā vērts aizpildīt, lai savienojums turpinātu darboties, ja režīms vēlāk tiek mainīts.

DSN izmantošana¶

DSN joprojām darbojas — DSN ir vienkārši vēl viens rekvizīts:

Key: DSN        Value: my_registered_dsn
Key: UID        Value: <user>
Key: PWD        Value: <password>        [Encrypted]

DSN jābūt reģistrētam digna resursdatorā tam pašam lietotāja kontam, ar kuru darbojas digna backend, un kā System DSN, ja digna darbojas kā pakalpojums. Visu, kas konfigurēts DSN, var pārrakstīt, pievienojot to arī kā rekvizītu.

Iestatīšana bez DSN ir dokumentētais noklusējums, jo tā novērš šo resursdatora puses stāvokli: savienojums ir pilnībā aprakstīts digna, un jaunā digna resursdatorā jāinstalē draiveris, bet nekas nav jākonfigurē.

Problēmu novēršana¶

Data source name not found / no default driver specified¶

Simptomi: - Poga Test ziņo par kļūdu, kurā minēts data source name not found, lai gan iestatīšana ir bez DSN

Cēloņi un risinājumi: 1. Driver vērtība neatbilst reģistrētam draivera nosaukumam — salīdziniet to ar cilni Drivers programmā ODBC Data Source Administrator (64-bit) vai ar odbcinst -q -d 2. Draiveris ir instalēts jūsu darbstacijā, bet ne digna resursdatorā 3. Draiveris ir 32 bitu, bet digna ir 64 bitu — instalējiet 64 bitu draiveri 4. Rekvizīta Driver vispār nav, un nav norādīts arī DSN 5. Linux un macOS draiveris ir instalēts, bet nav reģistrēts — tā vietā norādiet pilnu ceļu uz draivera bibliotēku vai reģistrējiet to failā odbcinst.ini

Savienojuma testam iestājas taimauts¶

Simptomi: - Test uzkaras un pēc aptuveni pusminūtes neizdodas

Cēloņi un risinājumi: 1. Resursdators vai ports nav sasniedzams no digna resursdatora — pārbaudiet ugunsmūri un, mākoņa avotiem, IP atļauto sarakstu 2. Resursdatora nosaukums ir pareizs, bet ports pieder citam pakalpojumam 3. Avotam nepieciešams vairāk nekā noklusējuma 30 sekundes, lai pieņemtu savienojumu — palieliniet DIGNA_SOURCE_LOGIN_TIMEOUT_SEC faila config.toml sadaļā [base] (0 gaida bezgalīgi) un restartējiet backend 4. Serverless gala punkts atsāk darbu pēc dīkstāves — mēģiniet vēlreiz, un, ja tas notiek regulāri, palieliniet pieteikšanās taimautu, kā aprakstīts iepriekš

Autentifikācija neizdodas, lai gan akreditācijas dati ir pareizi¶

Simptomi: - Draiveris ziņo par nederīgiem akreditācijas datiem, bet tas pats lietotājs darbojas citā SQL klientā

Cēloņi un risinājumi: 1. Parole satur ; — ietveriet vērtību figūriekavās: {p@ss;word} 2. Vērtībā tika iekopēta atstarpe beigās 3. Draiveris sagaida konkrētu autentifikācijas mehānismu — piemēram, AuthMech Hive un Databricks draiveriem vai authenticator Snowflake 4. Vērtība tika saglabāta šifrēta un pēc tam rediģēta — šifrētas vērtības nevar nolasīt atpakaļ, tāpēc ievadiet noslēpumu no jauna pilnībā 5. Tokena derīgums ir beidzies — personīgās piekļuves tokeni un programmatic access tokeni tiek izsniegti ar derīguma termiņu

Datu avota ekrānā netiek piedāvāta gaidītā datubāze vai shēma¶

Simptomi: - Pievienojot datu avotu, trūkst katalogu, shēmu vai tabulu

Cēloņi un risinājumi: 1. Savienojums norāda uz citu datubāzi — skatiet Kuru datubāzi redz savienojums 2. Savienojuma lietotājam nav lasīšanas tiesību shēmā vai datu vārdnīcā 3. Technology neatbilst avotam, tāpēc digna vaicā nepareizo datu vārdnīcu 4. Snowflake gadījumā lietotājam nav piešķirta noklusējuma noliktava (warehouse) un nav norādīts rekvizīts Warehouse, tāpēc metadatu vaicājumus nevar izpildīt

Profilēšana neizdodas, lai gan savienojuma tests ir veiksmīgs¶

Simptomi: - Test ir veiksmīgs, bet inspekcija neizdodas, kad tiek veidotas darba tabulas

Cēloņi un risinājumi: 1. Ir izvēlēta Permanent profilēšana, un savienojuma lietotājs nevar izveidot tabulas shēmā Work Schema — piešķiriet tiesības vai pārslēdzieties uz Session vai Standard 2. Work Schema ir tukša vai norāda uz neesošu shēmu, kamēr ir izvēlēta Permanent profilēšana 3. Ir izvēlēta Session profilēšana, un savienojuma lietotājs nedrīkst izveidot pagaidu tabulas 4. Ilgstošs profilēšanas vaicājums sasniedz vaicājuma taimautu — palieliniet DIGNA_SOURCE_QUERY_TIMEOUT_SEC faila config.toml sadaļā [base] (noklusējums 3600 sekundes, 0 atspējo taimautu)

Labākā prakse¶

DARĪT:

• Instalējiet un reģistrējiet draiveri digna resursdatorā pirms savienojuma konfigurēšanas
• Atzīmējiet Encrypted katrai parolei un tokenam
• Noklikšķiniet Test pirms saglabāšanas un testējiet vēlreiz pēc paroles maiņas
• Nosauciet savienojumus pēc avota un vides, piemēram, sales_dwh_prod
• Piešķiriet digna atsevišķu datubāzes lietotāju, ar tikai lasīšanas tiesībām, ja pietiek ar Standard profilēšanu
• Uzturiet vienu savienojumu katrai avota datubāzei un pievienojiet otru, nevis pārslēdziet pirmo

NEDARĪT:

• Glabāt noslēpumus nešifrētus vai koplietot vienu datubāzes lietotāju starp digna un citiem rīkiem
• Izmantot 32 bitu draiveri ar 64 bitu digna instalāciju
• Paļauties uz User DSN, ja digna darbojas kā pakalpojums — tas nebūs redzams
• Ievietot rekvizītā vērtību, kas satur ;, bez figūriekavām
• Norādīt Work Schema uz shēmu, kurā atrodas avota dati

Atbalsts¶

Nepieciešama palīdzība ar datubāzes savienojumu?

• E-pasts: support@digna.ai
• Dokumentācija: https://docs.digna.ai
• Tīmekļa vietne: https://www.digna.ai

Izlaidums: 2026.06
© 2026 digna GmbH — www.digna.ai