Przegląd połączeń z bazami danych¶

Spis treści¶

1. Jak działają połączenia
2. Przewodniki dla technologii
3. Wymaganie wstępne: instalacja sterownika ODBC na hoście digna
4. Tworzenie połączenia z bazą danych
5. Właściwości ODBC
6. Szyfrowanie wartości właściwości
7. Testowanie połączenia
8. Którą bazę danych widzi połączenie
9. Tryb profilowania i Work Schema
10. Użycie DSN zamiast tego
11. Rozwiązywanie problemów

Jak działają połączenia¶

digna sięga do każdej technologii źródłowej przez ODBC. Połączenie to lista właściwości ODBC, które wprowadzasz jako pary klucz/wartość. Gdy digna otwiera połączenie, łączy te pary w ciąg połączenia — Key=Value, rozdzielone ;, w podanej przez Ciebie kolejności — i przekazuje go menedżerowi sterowników ODBC na hoście digna.

To właśnie samodzielne wprowadzanie właściwości sprawia, że konfiguracja jest bez DSN: połączenie niesie ze sobą wszystko, czego potrzebuje sterownik, więc na hoście nie trzeba rejestrować żadnego źródła danych ODBC (DSN). To zalecany sposób konfigurowania digna, ponieważ definicja połączenia znajduje się w całości w digna i przenosi się razem z nią.

Dlaczego ODBC¶

Wcześniejsze wydania oferowały wybór między sterownikiem dla danej technologii a ODBC, wskazywany przełącznikiem Use ODBC. Od wydania 2026.06 digna opiera się wyłącznie na ODBC. Jeden standardowy interfejs daje więcej niż zestaw sterowników pisanych na miarę:

• Uwierzytelnianie — uwierzytelnianie jest częścią ODBC, więc połączenie może korzystać ze wszystkiego, co obsługuje jego sterownik: haseł, tokenów i PAT-ów, Kerberosa i Active Directory, MFA i logowania jednokrotnego przez przeglądarkę, tożsamości chmurowych, certyfikatów klienta i TLS. Nowe metody pojawiają się wraz z aktualizacją sterownika, a nie po oczekiwaniu na wydanie digna.
• Sterowniki utrzymywane przez dostawców baz danych — sterownik producenta nadąża za nowymi wersjami serwera i poprawkami bezpieczeństwa, a Ty możesz aktualizować go we własnym tempie, niezależnie od digna.
• Jeden sposób konfigurowania wszystkiego — każda technologia to lista właściwości klucz/wartość, z tym samym interfejsem, tym samym szyfrowaniem wartości wrażliwych i tą samą diagnostyką, zamiast innego zestawu pól dla każdego źródła.
• Strojenie i zasięg — opcje sterownika, takie jak limity czasu, ustawienia TLS, serwery proxy i rozmiary pobierania, są dostępne dla każdego źródła, a podłączyć można każdą technologię ze zgodnym sterownikiem ODBC, również taką, dla której digna nie publikuje osobnego przewodnika.

Przewodniki dla technologii¶

Nazwy właściwości różnią się w zależności od sterownika, a każda technologia ma jeden lub dwa szczegóły, których nie mają pozostałe. Poniższe przewodniki obejmują tę część; ta strona obejmuje stronę digna, która jest taka sama dla wszystkich.

Wymaganie wstępne: instalacja sterownika ODBC na hoście digna¶

digna otwiera połączenia źródłowe z serwera, na którym działa backend digna, a nie z przeglądarki. Sterownik ODBC musi więc być zainstalowany na tej maszynie, a jego nazwa zarejestrowana w lokalnym menedżerze sterowników.

odbcinst -q -d

odbcinst -q -d

Zamiast zarejestrowanej nazwy wszystkie popularne menedżery sterowników akceptują też pełną ścieżkę do biblioteki sterownika, na przykład Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. Przydaje się to, gdy sterownik jest zainstalowany, ale niezarejestrowany.

Tworzenie połączenia z bazą danych¶

Otwórz Admin Panel, przejdź na zakładkę Database Connections i kliknij Add DB Connection. Ekran pyta o pięć rzeczy:

Połączeniem zarządza się centralnie, a następnie przypisuje się je do jednego lub kilku projektów, więc to samo połączenie może obsługiwać wiele projektów.

Właściwości ODBC¶

Kliknij Add Property dla każdej właściwości i wypełnij Key, Value, a dla sekretów — pole wyboru Encrypted. Każdy przewodnik technologiczny wymienia przykładowy zestaw dla danej technologii, który dostosowujesz do swojej wersji sterownika i serwera — zobacz uwagę powyżej.

Niezależnie od sterownika zestaw właściwości obejmuje te same cztery rzeczy:

• Driver — zarejestrowaną nazwę sterownika, jak opisano powyżej.
• Adres serwera — klucz różni się w zależności od sterownika: SERVER, HOST, DBCNAME, Server albo, w przypadku Oracle, deskryptor połączenia DBQ.
• Poświadczenia — zwykle UID i PWD; Snowflake używa UID oraz token, a Databricks dosłownego użytkownika token wraz z osobistym tokenem dostępu w PWD.
• Bazę danych lub katalog, w którym się pracuje, jeśli technologia je ma — zobacz Którą bazę danych widzi połączenie.

Wszystko inne, co dokumentuje sterownik, można dodać w ten sam sposób — pulę połączeń, limity czasu gniazd, ustawienia Kerberosa, ustawienia serwera proxy. digna nie interpretuje właściwości; jedynie je przekazuje.

Szyfrowanie wartości właściwości¶

Zaznacz Encrypted dla każdej właściwości, która zawiera sekret — PWD, token, klucz tajny klienta. Wartość jest wtedy szyfrowana przed zapisaniem w repozytorium digna, maskowana na ekranie i odszyfrowywana dopiero przy składaniu ciągu połączenia.

Właściwości, które nie są sekretami — nazwa sterownika, host, port, baza danych — najlepiej zostawić niezaszyfrowane, aby pozostały czytelne dla osoby, która będzie później utrzymywać połączenie.

Testowanie połączenia¶

Kliknij Test w oknie Add DB Connection przed zapisaniem. Test korzysta z wartości aktualnie znajdujących się w formularzu i nawiązuje rzeczywiste połączenie, więc zgłasza dokładnie to, na co natrafiłaby inspekcja — błędną nazwę sterownika, odrzucone hasło, nieosiągalny host. Nic nie jest zapisywane: połączenie testowe jest wycofywane niezależnie od tego, czy się powiedzie, czy nie.

W przypadku istniejącego już połączenia najedź na jego wiersz w zakładce Database Connections i kliknij ikonę wtyczki, aby przetestować je ponownie. To najszybszy sposób sprawdzenia, czy źródło jest osiągalne po rotacji hasła lub zmianie w zaporze.

Którą bazę danych widzi połączenie¶

Gdy dodajesz źródło danych, digna udostępnia katalogi, schematy i tabele, do których połączenie może sięgnąć. Jak daleko sięga, zależy od technologii:

Tryb profilowania i Work Schema¶

Tryb profilowania określa, jak digna przetwarza dane i oblicza metryki:

• Standard: metryki są obliczane bezpośrednio na tabelach źródłowych, bez kopiowania danych.
• Permanent: dane z inspekcjonowanego dnia są kopiowane do tabeli trwałej, a metryki obliczane są na skopiowanych danych.
• Session: dane są kopiowane do tabeli sesyjnej lub tymczasowej, a metryki obliczane są na tych danych tymczasowych.

Tryb decyduje o tym, co musi być dozwolone użytkownikowi połączenia:

Standard wyłącznie odczytuje, co czyni go trybem do wyboru, gdy digna otrzymuje dostęp tylko do odczytu. Work Schema jest odczytywany jedynie przy Permanent, ale i tak warto go wypełnić, aby połączenie działało dalej, jeśli tryb zostanie później zmieniony.

Użycie DSN zamiast tego¶

DSN nadal działa — DSN to po prostu kolejna właściwość:

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

DSN musi być zarejestrowany na hoście digna, dla tego samego konta użytkownika, na którym działa backend digna, oraz jako System DSN, gdy digna działa jako usługa. Wszystko, co jest skonfigurowane w DSN, można nadpisać, dodając to również jako właściwość.

Tryb bez DSN jest udokumentowanym ustawieniem domyślnym, ponieważ pozwala uniknąć takiego stanu po stronie hosta: połączenie jest w pełni opisane w digna, a nowy host digna potrzebuje zainstalowanego sterownika, ale niczego skonfigurowanego.

Rozwiązywanie problemów¶

Nie znaleziono nazwy źródła danych / nie określono domyślnego sterownika¶

Objawy: - Przycisk Test zgłasza błąd wspominający data source name not found, mimo że konfiguracja jest bez DSN

Przyczyny i rozwiązania: 1. Wartość Driver nie odpowiada żadnej zarejestrowanej nazwie sterownika — porównaj ją z zakładką Drivers Administratora źródeł danych ODBC (64-bitowego) albo z odbcinst -q -d 2. Sterownik jest zainstalowany na Twojej stacji roboczej, ale nie na hoście digna 3. Sterownik jest 32-bitowy, podczas gdy digna jest 64-bitowa — zainstaluj sterownik 64-bitowy 4. Właściwości Driver w ogóle brakuje, a DSN również nie podano 5. W systemach Linux i macOS sterownik jest zainstalowany, ale niezarejestrowany — podaj zamiast tego pełną ścieżkę do biblioteki sterownika albo zarejestruj go w odbcinst.ini

Test połączenia przekracza limit czasu¶

Objawy: - Test zawiesza się, a następnie kończy się niepowodzeniem po mniej więcej pół minuty

Przyczyny i rozwiązania: 1. Host lub port nieosiągalne z hosta digna — sprawdź zaporę, a w przypadku źródeł chmurowych listę dozwolonych adresów IP 2. Nazwa hosta jest poprawna, ale port należy do innej usługi 3. Źródło potrzebuje więcej niż domyślne 30 sekund, aby przyjąć połączenie — zwiększ DIGNA_SOURCE_LOGIN_TIMEOUT_SEC w sekcji [base] pliku config.toml (0 oznacza oczekiwanie bez ograniczeń) i uruchom ponownie backend 4. Bezserwerowy punkt końcowy wybudza się ze stanu bezczynności — ponów próbę, a jeśli zdarza się to regularnie, zwiększ limit czasu logowania jak wyżej

Uwierzytelnianie zawodzi, choć poświadczenia są poprawne¶

Objawy: - Sterownik zgłasza nieprawidłowe poświadczenia, ale ten sam użytkownik działa w innym kliencie SQL

Przyczyny i rozwiązania: 1. Hasło zawiera ; — ujmij wartość w nawiasy klamrowe: {p@ss;word} 2. Do wartości skopiowano końcową spację 3. Sterownik oczekuje określonego mechanizmu uwierzytelniania — na przykład AuthMech w sterownikach Hive i Databricks albo authenticator w Snowflake 4. Wartość została zapisana jako zaszyfrowana, a następnie edytowana — zaszyfrowanych wartości nie można odczytać, więc wprowadź sekret ponownie w całości 5. Token wygasł — osobiste tokeny dostępu i programowe tokeny dostępu są wydawane z datą wygaśnięcia

Ekran źródła danych nie udostępnia oczekiwanej bazy lub schematu¶

Objawy: - Przy dodawaniu źródła danych brakuje katalogów, schematów lub tabel

Przyczyny i rozwiązania: 1. Połączenie wskazuje inną bazę danych — zobacz Którą bazę danych widzi połączenie 2. Użytkownikowi połączenia brakuje uprawnień odczytu do schematu albo do słownika danych 3. Technology nie odpowiada źródłu, więc digna odpytuje niewłaściwy słownik danych 4. W przypadku Snowflake użytkownik nie ma przypisanego domyślnego magazynu i nie podano właściwości Warehouse, więc zapytania o metadane nie mogą się wykonać

Profilowanie zawodzi, choć test połączenia się powiódł¶

Objawy: - Test przechodzi, ale inspekcja kończy się niepowodzeniem przy tworzeniu tabel roboczych

Przyczyny i rozwiązania: 1. Wybrano profilowanie Permanent, a użytkownik połączenia nie może tworzyć tabel w Work Schema — nadaj uprawnienia albo przełącz się na Session lub Standard 2. Work Schema jest puste albo wskazuje nieistniejący schemat, podczas gdy wybrano profilowanie Permanent 3. Wybrano profilowanie Session, a użytkownik połączenia nie może tworzyć tabel tymczasowych 4. Długo działające zapytanie profilujące osiąga limit czasu zapytania — zwiększ DIGNA_SOURCE_QUERY_TIMEOUT_SEC w sekcji [base] pliku config.toml (domyślnie 3600 sekund, 0 wyłącza limit)

Dobre praktyki¶

RÓB TAK:

• Zainstaluj i zarejestruj sterownik na hoście digna, zanim skonfigurujesz połączenie
• Zaznaczaj Encrypted dla każdego hasła i każdego tokenu
• Klikaj Test przed zapisaniem i testuj ponownie po rotacji hasła
• Nazywaj połączenia według źródła i środowiska, na przykład sales_dwh_prod
• Daj digna dedykowanego użytkownika bazy danych, tylko do odczytu tam, gdzie wystarcza profilowanie Standard
• Utrzymuj jedno połączenie na każdą źródłową bazę danych i dodawaj drugie zamiast przestawiać pierwsze

NIE RÓB TAK:

• Nie przechowuj sekretów bez szyfrowania i nie współdziel jednego użytkownika bazy danych między digna a innymi narzędziami
• Nie używaj sterownika 32-bitowego z 64-bitową instalacją digna
• Nie polegaj na DSN użytkownika, gdy digna działa jako usługa — nie będzie widoczny
• Nie umieszczaj we właściwości wartości zawierającej ; bez nawiasów klamrowych
• Nie kieruj Work Schema na schemat zawierający dane źródłowe

Wsparcie¶

Potrzebujesz pomocy przy połączeniu z bazą danych?

• E-mail: support@digna.ai
• Dokumentacja: https://docs.digna.ai
• Strona internetowa: https://www.digna.ai

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