Przejdź do treści

Wsparcie Impuls BPSC i administracja bazą Oracle

Przejmujemy bazę danych, na której pracuje Impuls - warstwę, która najczęściej zostaje niczyja. Zdalnie, w całej Polsce.

Gdy Impuls zaczyna działać wolno albo moduł zwraca błąd bazy, zaczyna się odsyłanie. Dostawca ERP wskazuje na infrastrukturę, firma IT na aplikację. Baza danych jest wtedy niczyja - a stoi na niej cała firma.

Ten podział nie wynika z niczyjej złej woli. Dostawca systemu odpowiada za aplikację i nie ma mandatu do zmian w infrastrukturze, a firma utrzymująca serwery kończy odpowiedzialność na systemie operacyjnym. Pomiędzy zostaje baza danych, o którą nikt nie ma obowiązku zapytać, dopóki działa. Wchodzimy dokładnie w tę warstwę.

Bazami Oracle zajmujemy się od dziesięciu lat. Najpierw w ochronie zdrowia, gdzie korzystało z nich oprogramowanie Kamsoftu, dziś w produkcji, gdzie pracuje na nich Impuls EVO. To dwa różne światy aplikacyjne, ale ta sama warstwa pod nimi - i te same konsekwencje, kiedy zostaje bez opieki.

Oracle 12cOracle 19cImpuls EVO

Objawy, które prawdopodobnie znasz

Żaden z nich nie brzmi jak problem bazy danych. Każdy nim bywa.

Zakres wsparcia

Wydajność i higiena bazy

  • Konfiguracja audytu i cykliczne czyszczenie śladu audytowego
  • Porządkowanie zadań diagnostycznych
  • Dobór wielkości i liczby logów powtórzeń pod realny wolumen zapisu

Archiwizacja i przestrzeń

  • Polityka retencji dopasowana do wolumenu i wymagań odtwarzania
  • Monitoring zapełnienia obszaru archiwalnego
  • Reakcja zanim brak miejsca zatrzyma bazę

Odtwarzanie i DR

  • Pełne testowe odtworzenie na osobnej maszynie, z mierzonym czasem
  • Odtwarzanie do wskazanego punktu w czasie
  • Ustalenie celów odtworzenia razem z osobami odpowiedzialnymi za procesy

Wsparcie przy pracach na danych

  • Korekty i uzupełnienia prowadzone ścieżką aplikacyjną systemu
  • Bez zapisu wprost do tabel, który podważa spójność i wsparcie dostawcy

Monitoring

  • Zdarzenia bazy podpięte pod stały nadzór
  • Filtrowanie szumu, żeby alert znaczył, że trzeba działać

Odtwarzanie: mierzymy, nie zakładamy

Kopia, której nigdy nie odtworzono, jest założeniem, nie zabezpieczeniem. Różnica między jednym a drugim wychodzi dokładnie w chwili, w której nie ma już czasu jej odkrywać.

Dlatego odtworzenie jest u nas procedurą, a nie improwizacją: ma spisaną instrukcję, ustaloną kolejność kroków i zapis każdego wykonania. Dla systemów krytycznych naszym standardem jest test odtworzeniowy nie rzadziej niż raz na kwartał, prowadzony na maszynie innej niż produkcyjna.

Czasu nie szacujemy z pamięci. Po każdym odtworzeniu odczytujemy twarde znaczniki czasu z RMAN i z dziennika alertów bazy, i rozróżniamy dwie wartości: czas od pierwszej próby do otwarcia bazy oraz czas samych operacji odtwarzania, bez przerw na diagnozowanie. Do porównania z docelowym RTO liczy się ta druga, bo w realnej awarii nie ma przerwy na noc.

Czego nie powie żadna deklaracja

Pierwszy zmierzony czas odtworzenia potrafi wypaść wielokrotnie dłużej od zakładanego RTO. U nas wypadł. Pełne odtworzenie zajęło wiele godzin, prawie w całości pochłoniętych odczytem plików danych.

Zaskoczeniem nie była jednak długość, a przyczyna. Wszystko wskazywało na problem z siecią, bo kopia leżała pod ścieżką sieciową. W rzeczywistości był to ten sam fizyczny dysk: kopia zapasowa i archiwalne logi rywalizowały o te same głowice, dysk pracował na granicy wysycenia, a odczyt jednego pliku danych zajmował kilkadziesiąt minut. Żaden komunikat błędu tego nie pokazał - proces wyglądał na zawieszony, choć cały czas postępował.

Wniosek przenosi się na każde środowisko: rozdziel katalog kopii, archiwalne logi i pliki danych na osobne wolumeny. Współdzielenie jednego dysku jest typową przyczyną wielokrotnego wydłużenia odtwarzania - i rzeczą, której nie widać, dopóki się jej nie zmierzy.

Właśnie po to robi się test. Żeby tę różnicę znaleźć wcześniej, a nie w trakcie awarii.

Obok pełnego odtworzenia prowadzimy odtwarzanie do wskazanego punktu w czasie. Przydaje się rzadziej po awarii sprzętu, a częściej po błędzie w danych, kiedy trzeba wrócić do stanu z konkretnej godziny.

Piszemy też dodatki do Impulsa

Nie tylko utrzymujemy bazę danych Impulsa. Tworzymy też rozszerzenia i integracje wokół systemu - i to zmienia jakość samego wsparcia.

Model danych Impulsa znamy z własnego kodu, a nie z opisu w dokumentacji. To różnica, której nie da się kupić osobno: kiedy przychodzi zgłoszenie opisane jako błąd modułu, nie zaczynamy od zgadywania, gdzie szukać. Potrafimy też odróżnić sytuację, w której trzeba poprawić dane, od tej, w której trzeba poprawić to, co je zapisuje.

Producenta Impulsa spotkasz dziś pod dwiema nazwami. BPSC działa w grupie Forterro, więc obie krążą równolegle i obie dotyczą tego samego systemu. Zmiana objęła dostawcę, nie system ani jego bazę danych.

Nie musisz od razu nic zmieniać

Trzy sposoby, w jakich najczęściej z nami pracują. Każdy działa osobno.

01

Wsparcie zadaniowe

Konkretny problem, konkretna wycena. Wchodzimy w jedną sprawę i zamykamy ją, bez umowy na utrzymanie.

02

Stała opieka nad bazą

Jako element umowy utrzymaniowej albo osobno, jeśli infrastrukturą zajmuje się już ktoś inny.

03

Dodatki do Impulsa

Rozszerzenia i integracje wokół systemu, osobno albo obok utrzymania bazy. Jedno wspiera drugie: kto pisze kod na tych danych, ten je zna.

Jak to wygląda wobec dostawcy ERP

Działamy w warstwie bazy danych i infrastruktury pod nią. Nie ingerujemy w aplikację w sposób, który naruszałby wsparcie dostawcy systemu, a korekty danych prowadzimy ścieżkami przewidzianymi przez sam system, nie zapisem wprost do tabel.

W praktyce oznacza to, że dostawca ERP zachowuje pełną odpowiedzialność za to, za co odpowiadał do tej pory. Zmienia się jedno: warstwa poniżej przestaje być niczyja.

Częste pytania

Impuls BPSC czy Forterro - o którym systemie mowa?
O tym samym. BPSC, producent Impulsa, działa dziś w grupie Forterro, więc obie nazwy krążą równolegle i obie prowadzą do tego samego systemu. Zmiana dotyczy dostawcy, nie systemu ani jego bazy danych.
Czy piszecie też dodatki do Impulsa?
Tak. Poza utrzymaniem bazy tworzymy rozszerzenia i integracje wokół systemu. Dla samego wsparcia ma to skutek, którego nie da się kupić osobno: model danych znamy z własnego kodu, a nie z dokumentacji, więc przy zgłoszeniu opisanym jako błąd modułu szybciej widać, gdzie w danych leży przyczyna.
Czy wchodzicie w spór z dostawcą ERP?
Nie. Dzielimy odpowiedzialność, a nie ją przejmujemy. Dostawca odpowiada za aplikację, my za warstwę bazy danych i infrastruktury pod nią. To układ, w którym nikt nie może już odesłać sprawy dalej.
Czy musimy zmieniać firmę obsługującą IT?
Nie. Najczęściej wchodzimy wyłącznie w warstwę bazy danych, obok dotychczasowego dostawcy usług IT. Jeśli obsługa infrastruktury działa dobrze, nie ma powodu jej ruszać.
Czy pracujecie zdalnie?
Tak. Administracja bazą danych nie wymaga obecności na miejscu, dlatego tę usługę realizujemy zdalnie w całej Polsce, niezależnie od tego, gdzie znajduje się zakład.
Czy potrzebujecie dostępu SYSDBA i jak go zabezpieczacie?
Tak, administracja bazą tego wymaga. Poświadczenie trzymamy w menedżerze haseł Keeper, a logowanie jest ograniczone do jednej wskazanej maszyny - samo posiadanie hasła nie wystarcza, żeby się połączyć. Dostęp obejmuje ślad audytowy bazy, który konfigurujemy i utrzymujemy, więc widać, kto i kiedy wykonał operacje. Dostęp możecie odebrać w każdej chwili.
Co, jeśli okaże się, że baza jest w złym stanie?
Mówimy to wprost, z podziałem na rzeczy wymagające reakcji od razu i takie, które można zaplanować na spokojnie. Nie mamy interesu w zamalowywaniu stanu: problem, o którym nie wiecie, wróci i tak, tylko w gorszym momencie i drożej.

Porozmawiajmy o Waszym środowisku

Napisz, co się dzieje z bazą albo z samym Impulsem. Odpowiemy, czy to warstwa, którą się zajmujemy, i jak moglibyśmy pomóc - bez zobowiązań po Waszej stronie.

Napisz do nas