Każdy z programistów ma własne typy klientów bazodanowych do wprowadzania zmian w zasobach danych pisanej/ych aplikacji. Dla wielu jest to zapewne stary, zasłużony phpMyAdmin, a inni mają bardziej wyszukane propozycje. Jak się domyślacie, sam należę do tej drugiej grupy. W związku z tym proponuję wykorzystanie HeidiSQL.

Jednak każdy kij ma dwa końce. O ile praca z ww. klientem bazodanowym jest bardzo intuicyjna, sprawna i … w ogóle, o tyle zdarzają się czasami problemy, oj poważne problemy dla osób „świeżych” w branży. Chodzi o blokadę krotki w tabeli, na której wykonywaliśmy pewne operacje. W przypadku, gdy nastąpi błąd na pewnej krotce i nieumiejętnie napisaliśmy zapytanie (bądź korzystaliśmy z graficznego interfejsu klienta, który nie zapewnia obudowy transakcyjnej), w pewnych okolicznościach może dojść do pospolitego zawieszenia aplikacji. A i nie myślcie, że wówczas restart klienta wystarczy. Oj nieee 🙂 Byłby to bajkowy świat i spowodowałby, że nie czytalibyście tego wpisu. Wtedy to akurat świat mści się na nas nie pozwalając wykonać żadnej operacji na wskazanej krotce i na domiar złego – zawsze!

Jestem pewien, że są osoby, które taka sytuacja doprowadziła do białej gorączki. Uspokajam, że są przynajmniej dwa wyjścia, rozwiązania problemu. Dlaczego przynajmniej? Bowiem tylko dwa znam, jako osoba luźno powiązana ze znajomością baz danych, ograniczona do wiedzy koniecznej i wymaganej przy budowie aplikacji wykorzystującej bazę SQL do przechowywania zasobów – bez żadnych fajerwerków.

Metoda brutalna

HeidiSQL jest w tym momencie niekluczowe. Można wykorzystać tę metodę w przypadku, gdy używamy innego klienta, bowiem rozwiązanie jest niezależne. Dlaczego jest to brutalne podejście? Krótka odpowiedź – restart serwera bazodanowego. Brutalne podejście, bowiem to jest ostateczność. Sam restart pozwala usunąć blokadę z krotki i pozwoli na operacje na niej – tak, te operacje, które wcześnie powodowały zawieszenie aplikacji.

Metoda procesowa

Bynajmniej nie chodzi tutaj o złożone procesy. Wystarczy odwiedzić w swoim kliencie (po podłączeniu z określonym hostem – serwerem DB) zakładkę Processes (X), gdzie X określa liczbę zidentyfikowanych procesów działających na serwerze DB. Jest to przynajmniej jeden proces (albowiem klient musi jakoś skomunikować się z bazą). Uwierzcie, że tych procesów na działającej prężnie aplikacji może być mnóstwo. Jeśli jednak mówimy o opisywanym w artykule problemie, będzie klika procesów, z czego przynajmniej jeden wyda się Wam podejrzany. Będzie on miał nienaturalnie długi czas działania. Można bez obaw zabić ten proces. Problem powinien zostać rozwiązany. Jednak, gdy nie nastąpił oczekiwany skutek odblokowania krotki, należy szukać procesu odpowiedzialnego za ten stan wśród kolejnych długo trwających procesów.

Obie opisane metody zostały wykorzystane  w praktyce i stanowiły konieczność. Żadne dane nie zostały utracone, a baza pozostała w stanie spójnym.