Database
 sql >> Baza danych >  >> RDS >> Database

Tabela rozwiązywania problemów Nie znaleziono błędów

Niedawno jeden z naszych klientów miał problemy z wstawieniem niektórych danych Oracle® do tabeli programu SQL Server. Wstawianie nie powiodło się, ponieważ tabela docelowa w instancji SQL Server nie była obecna w bazie danych, z którą łączył się klient.

Ostatecznie rozwiązanie tego problemu było najprostsze. To narzędzie do rozwiązywania problemów zawiera to rozwiązanie i inne, próbując przedstawić listę potencjalnych rozwiązań problemu w logicznej kolejności. Chociaż narzędzie do rozwiązywania problemów opiera się na sterowniku Easysoft ODBC wykorzystującym SQL Server jako docelową bazę danych, wiele kroków ma zastosowanie do innych sterowników opartych na unixODBC dla innych baz danych.

  1. Sprawdź źródło danych (DSN) dla docelowej bazy danych.

    Zwykle będzie to zdefiniowane w /etc/odbc.ini.

    Ważne Nie pomijaj tych kroków tylko dlatego, że DSN jest kopią działającej konfiguracji na innym komputerze. Zwłaszcza jeśli ta konfiguracja robocza jest na innej platformie i/lub używa innej wersji sterownika. Różne wersje sterownika ODBC mogą w różny sposób analizować plik odbc.ini, na przykład niektóre mogą używać ostatniej wersji atrybutu DSN lub DSN, którą znajdują, gdy występują duplikaty, niektóre mogą używać ostatniej. Ponadto inny sterownik na innej platformie może przestać analizować plik odbc.ini, jeśli w pliku występuje problematyczny znak, taki jak powrót karetki.

    • Sprawdź, czy istnieje tylko jedna kopia źródła danych. Jeśli istnieje wiele wersji źródła danych, zmień ich nazwy lub usuń inne wersje. To znaczy, chcesz to:
      [MYDSN]
      Database=MYDB
      

      —Lub—

      [MYDSN1]
      Database=MYDB1
      
      [MYDSN2]
      Database=MYDB2
      

      Nie

      [MYDSN]
      Database=MYDB
      
      [MYDSN]
      Database=MYDB
      
    • Gdy masz pewność, że masz tylko jedną kopię DSN, sprawdź, czy DSN zawiera tylko wiersz określający docelową bazę danych. Czyli chcesz to:
      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      .
      .
      .
      [ANOTHERDSN]
      

      Nie

      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      Database=MYDB2
      .
      .
      .
      [ANOTHERDSN]
      

      —Lub—

      [MYDSN]
      Database=MYDB
      Server=MYMACHINE
      Database=
      .
      .
      .
      [ANOTHERDSN]
      
  2. Jeśli nie określisz wyraźnie bazy danych, sprawdź u administratora DBA, czy domyślną bazą danych użytkownika jest ta, o której myślisz. Na przykład w SQL Server można skonfigurować logowanie, aby połączyć się z konkretną bazą danych, więc w:
    [MYDSN]
    Database=MYDB
    Server=MYMACHINE
    User=MYUSER.
    .
    .
    [ANOTHERDSN]
    

    MYUSER może początkowo połączyć się, powiedzmy, AdventureWorks, jeśli login został skonfigurowany do określonej bazy danych, lub do głównej bazy danych, jeśli tak nie jest.

  3. Sprawdź, czy łączysz się z DSN, o którym myślisz. Nawet jeśli dodałeś DSN do istniejącej wersji, powiedzmy /etc/odbc.ini, nie oznacza to, że menedżer sterowników szuka w tym pliku. W zależności od tego, jak zbudowany jest menedżer sterowników lub ustawione jest środowisko, może on wyglądać w innym miejscu. Aby to sprawdzić, spróbuj zakomentować atrybut Driver w źródle danych. Jeśli nadal możesz się połączyć, używasz innej wersji DSN. Użyj programu, takiego jak strace lub truss, aby dowiedzieć się, który plik odbc.ini jest używany. Na przykład:
    $ more /etc/odbc.ini
    [MYDSN]
    #Driver=Easysoft ODBC-SQL Server
    $ /usr/local/easysoft/unixODBC/bin/isql.sh -v MYDSN
    SQL>
    $ strace -o -f /tmp/odbc.log /usr/local/easysoft/unixODBC/bin/isql.sh -v MYDSN
    $ grep odbc.ini /tmp/odbc.log
    

    Jeśli skopiowałeś DSN z innego komputera, spróbuj powtórzyć ten proces na tym komputerze, aby zweryfikować lokalizację źródłowego DSN.

  4. Sprawdź, czy łączysz się z systemem DBMS, którym myślisz, że jesteś. Na przykład, jeśli nie jest to zbyt uciążliwe, spróbuj wstrzymać / zatrzymać docelową instancję / usługę dla DBMS. Jeśli nadal możesz się połączyć, łączysz się z systemem DBMS na innej maszynie. Być może twoja sieć została skonfigurowana w taki sposób, że inna maszyna może wydawać się, że ma ten sam adres IP, co ten określony w DSN.
  5. W isql wpisz „pomoc”. Jaka nazwa bazy danych jest wyświetlana na liście zwróconych tabel? Czy to ten, którego oczekujesz? Jeśli nie, co się stanie, jeśli wpiszesz:
    use database
    

    Zastąp bazę danych z nazwą docelowej bazy danych. Jeśli nie możesz zmienić bazy danych, sprawdź u swojego administratora, czy istnieje wyzwalacz logowania, który kontroluje dostęp do baz danych według adresu IP. W SQL Server Management Studio wyzwalacze logowania znajdują się w INSTANCE> Obiekty serwera> Wyzwalacze.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Reorgs bazy danych – dlaczego mają znaczenie

  2. Logowanie za pomocą usług zewnętrznych

  3. Używanie wzorców przepływu pracy do zarządzania stanem dowolnej jednostki

  4. Sprawa dla ZAMIAST wyzwalaczy – część 1

  5. Łączenie się z Teradata w IRI Workbench