Diagnostyka zapytań wykonywanych do plików BWS

Artykuł stanowi instrukcję konfiguracji narzędzi i plików, które pozwolą na zrzut i analizę zapytań SQL wykonywanych na bazach danych oprogramowania Bridgemate.

Wymagane oprogramowanie to:

• Microsoft Access, kompatybilny z plikami formatu Access2000 (tu użyto Accessa 2013)
• serwer SQL Server (tu: SQL Server Express 2014)
• SQL Server Import and Export Data (tu: z pakietu wersji 2014)
• SQL Server Profiler (tu: w wersji 17)

Operacje przedstawione w poniższym opisie prawdopodobnie są wykonalne z dowolnym innym serwerem bazodanowym, ale artykuł opisuje SQL Server ze względu na obecność w systemach Windows gotowych sterowników bazodanowych do SQL Server kompatybilnych z bazami Accessa, oraz dostępność przyjaznych użytkownikowi narzędzi do analizy operacji serwera baz danych.

Po przejrzeniu różnych porad i odpowiedzi znalezionych w Internecie, nie udało mi się skutecznie skorzystać żadnej z metod przeznaczonych dla konkretnych sterowników bazodanowych (Jet/ODBC).

Podstawowy pomysł miał więc polegać na przekierowaniu całej komunikacji z plikiem BWS przez pośredniczący serwer bazodanowy, dla którego można zastosować dowolne narzędzia analizy wykonywanych operacji. Pierwotna koncepcja rysowała się więc następująco:

1. Utworzyć bazę danych SQL Server w trybie tzw. linked server, mapując całą jej zawartość na oryginalny BWS.
2. Utworzyć pusty plik Accessa 2000 i połączyć w nim tabele z tabelami tak utworzonej bazy danych.
3. Wszelkie programy używające pliku BWS kierować do tego drugiego pliku BWS, zamiast oryginału.

W ten sposób wszystkie operacje wykonywałyby się na zawartości oryginalnego pliku, ale można by je łatwo przeanalizować podczas przejścia przez serwer bazy danych.

Niestety, prawidłowa konfiguracja linked server kierującego do pliku BWS mnie przerosła, procedura została więc zmodyfikowana:

1. Zaimportować całą zawartość oryginalnego pliku BWS do bazy danych SQL Server.
2. A dalej zgodnie z planem - utworzyć plik Accessa łączący się do tej bazy danych i korzystać z niego.

Zaletą tego podejścia jest zachowanie oryginalnej zawartości pliku BWS - więc łatwa powtarzalność testów. Do tego metoda uniezależnia się od wyboru konkretnego serwera bazy danych, choć pozostałem przy SQL Server.

1. Uruchamiamy SQL Server 2014 Import and Export Data, czyli kreator importu/eksportu danych.
2. Wybieramy jako źródło danych sterownik Jet Database Engine dla formatu Accessa (JDE to format Accessa 2000, ADE to format nowszy).
3. Wybieramy nasz plik BWS, pamiętając o wyszukiwaniu wszystkich plików, a nie tylko plików *.mdb.
4. Pliki BWS nie są zabezpieczane hasłem, więc możemy przejsć dalej bez podawania danych uwierzytelniających.
5. Jako docelową bazę, wybieramy natywny sterownik SQL Server.
6. Wybieramy naszą instancję SQL Server oraz dane uwierzytelniania (domyślnie do lokalnej instancji uwierzytelnia się poświadczeniami konta systemowego).
7. Za pośrednictwem przycisku New..., tworzymy nową bazę danych.
8. Będzie to docelowa baza danych dla importu. Jeśli chcemy zaimportować do istniejącej bazy danych, wybieramy ją w tym kroku.
9. Wybieramy kopiowanie wszystkich danych w tabelach lub widokach.
10. Oznczamy wszystkie tabele, jakie udało się wylistować z pliku BWS jako importowane do bazy danych.
11. Możemy pominąć tabelę Settings (o tym później), możemy również dla każdej tabeli zmodyfikować sposób importu (Edit mappings...), pozostawiając kolumny tabeli bez zmian, ale np. wybierając zastąpienie istniejących rekordów (jeśli importujemy do istniejącej bazy danych).
12. Zatwierdzamy natychmiastowe wykonanie importu.
13. Uruchamiamy import.
14. Gotowe!

1. Tworzymy nową bazę danych Access dla komputerów stacjonarnych, wybieramy docelowe ścieżkę i format.
2. Wybieramy format Access 2000, zatwierdzamy nazwę pliku (na razie może pozostać *.mdb).
3. Zamykamy domyślną tabelę roboczą, przechodzimy do wstęgi Dane zewnętrzne, wybieramy pozycję Baza danych ODBC.
4. Nie importujemy kopii danych z SQL Server, będziemy tworzyć tabele połączone.
5. W zakładce Komputerowe źródło danych skonfigurujemy źródło danych z naszej bazy SQL Server.
6. Bez uprawnień administracyjnych jesteśmy w stanie zdefiniować źródło jedynie dla aktualnego użytkownika, to wystarczy.
7. Określamy komunikację przy użyciu natywnego sterownika SQL Server.
8. Nadajemy źródłu nazwę i opis, a także kierujemy je do naszej instancji SQL Server.
9. Ustawiamy dane uwierzytelnienia do serwera (jak przy imporcie z oryginalnego BWS).
10. Zmieniamy domyślną bazę danych (Change the default database to:) na naszą kopię oryginalnego pliku BWS.
11. Kończymy kreator z domyślnymi parametrami w ostatniej karcie.
12. Możemy jeszcze przetestować połączenie z naszą bazą, na wypadek gdybyśmy np. określili złą lokalizację serwera i nazwę instancji SQL Server.
13. Wybieramy tak utworzone źródło danych. W przyszłości nie ma potrzeby tworzenia nowego źródła z każdym importem, możemy skierować nasze źródło na inną bazę danych poprzez aplet: Panel Sterowania -> Narzędzia Administracyjne -> Źródła danych (ODBC), przeprowadzając ponowną konfigurację, z wyborem innej domyślnej bazy danych.
14. Wybieramy wszystkie tabele zaimportowane wcześniej z pliku BWS poza Settings.
15. Następnie Access pyta nas o klucze podstawowe wszystkich tabel. Ich ustawienie jest niezbędne do tego, by tak spreparowany plik Access mógł być używany nie tylko w trybie do odczytu, ale i do zapisu. Przeważnie kluczem podstawowym jest kolumna ID...
16. ...poza tabelami HandEvaluation, HandRecord, PlayerNumbers, RoundData i Tables.
17. Zmieniamy nazwy zaimportowany tabel połączonych, usuwając przedrostki wynikające z przestrzeni nazw tabel w bazie danych.
18. Po tej operacji powinniśmy mieć w pliu z powrotem oryginalne nazwy tabel z pliku BWS.
19. Możemy podejrzeć kopie oryginalnych danych, pobranych z SQL Server.
20. Pozostaje skopiować oryginalną tabelę Settings. Tabeli tej nie dało się zaimportować jako połączonej z SQL Server - jedyny klucz podstawowy, jaki może ona posiadać (Section), niekoniecznie znajduje się zawsze w pliku BWS, poza tym zawiera pola typu bit, które kiepsko się mapują między silnikami bazodanowymi. Oznacza to, że nie będziemy w stanie podsłuchać zapytań do tabeli Settings, ale rzadko kiedy są one nietrywialne i jeśli nie zajmujemy się konkretnie zapisem i odczytem ustawień (np. podziałem ustawień między ustawieniami definiowanymi przez BWS a definiowanymi przez BCS), nie będzie nam to potrzebne.
21. We wstędze Dane zewnętrzne wybieramy źródło Access.
22. W oknie wyboru pliku musi ręcznie wymusić wyświetlenie wszystkich plików w katalogu (nasz BWS ma inne rozszerzenie niż Access się spodziewa).
23. Wybieramy opcję importu kopii tabeli. Moglibyśmy utworzyć kolejną tabelę połączoną, ale wówczas modyfikowalibyśmy oryginalne dane.
24. Wybieramy tabelę Settings.
25. Kończymy kreator.
26. Mamy teraz gotowy kompletny interfejs identyczny z oryginalnym plikiem BWS (z dokładnością do widoków danych). Możemy zmienić mu rozszerzenie na *.bws.

1. Uruchamiamy SQL Server Profiler, wybieramy nowy zrzut: New trace
2. Łączymy się z naszą instancją SQL Server.
3. Domyślne opcje działają calkiem nieźle, możemy ewentualnie automatycznie zrzucać dane do pliku (Save to file:)...
4. ...albo skonfigurować zrzucanie tylko niektórych typów operacji na bazie danych.
5. Zrzut został rozpoczęty, możemy uruchomić program używający plików BWS (np. Kolektor).
6. Wybieramy nasz spreparowany plik BWS zamiast pliku oryginalnego.
7. W oknie SQL Server Profiler widzimy kolejne zrzucane pakiety.
8. Zamknięcie połączenia z plikiem BWS (zamknięcie Kolektora) również zostaje odnotowane. Możemy zatrzymać zrzut (Stop trace w pasku narzędzi).
9. Zrzut możemy zapisać (Ctrl+S) do pliku *.trc, skojarzonego z SQL Server Profiler, celem późniejszej analizy.