Drugie rozwiązanie to stosowanie tzw. wielowersyjności (każdy użytkownik korzysta z bazy tak, jakby był jej jedynym użytkownikiem) lub automatycznego kopiowania części bazy do jej migawki (snapshot) - użytkownik nie blokuje dostępu do bazy innym użytkownikom, korzysta bowiem z kopii danych. Po zakończeniu modyfikacji pobranych wierszy z kopii bazy, następuje przekopiowanie ich do głównych tabel bazy. Przedtem jednak konieczne jest sprawdzenie, czy nie wystąpił konflikt z innymi użytkownikami, którzy także mogli uaktualniać wiersze bazy. Jeżeli konfliktu nie ma, następuje uaktualnienie bazy i zakończenie transakcji. Jeżeli zaś pojawił się, użytkownika (a właściwie jego program) powiadamia się, że operacja nie może być zakończona, gdyż używane przez niego wiersze zostały zmodyfikowane przez innego użytkownika. Pozwala mu to pobrać dane na nowo i zdecydować, w jaki sposób zamierza kontynuować działanie.

Obsługa dużej liczby użytkowników

Każde zapytanie użytkownika do bazy danych jest obsługiwane przez pojedynczy proces lub wątek systemowy. Niektóre z serwerów baz danych realizują własną obsługę wątków, jest to jednak rozwiązanie zanikające, gdyż oznacza jedynie powielanie wysiłku w dziedzinie dobrze realizowanej w większości systemów operacyjnych. W efekcie większość serwerów baz danych korzysta z możliwości systemowych obsługi wątków lub procesów.

Nie oznacza to jednak, że każdy z użytkowników otrzymuje własny proces lub wątek przy każdej sesji połączeniowej z bazą. Typowy proces wymaga w Unixie co najmniej 500 kB pamięci, toteż obsługa tysiąca użytkowników wymagałaby komputera o niesłychanie dużych zasobach systemowych. Jednakże większość dołączonych do systemu użytkowników ponad 90% czasu jest nieaktywnych (tzn. nie realizuje żadnej transakcji). Dlatego w większości baz danych utrzymuje się w stanie aktywności pewną liczbą wątków, które są przydzielane kolejnym użytkownikom wykonującym aktualnie operacje w systemie.

Taki sposób pracy umożliwia również optymalizację wykorzystania zasobów systemowych za pomocą tzw. monitorów transakcji (np. Tuxedo firmy BEA lub Novell, Encina firmy Transarc, TopEnd firmy NCR), aktywnie przydzielających wątki, zapewniających bezpieczeństwo transakcji, obsługujących środowisko rozproszone z wieloma serwerami baz danych i inne. Ostatnio pewne właściwości typowego serwera transakcyjnego stanowią coraz częściej standardowe wyposażenie motoru bazy danych, zapewniając obsługę dużej liczby użytkowników.

Bezpieczeństwo danych

Systemy przetwarzania transakcyjnego stanowią o sukcesie lub porażce codziennej działalności większości współczesnych przedsiębiorstw i organizacji. Z tego powodu składowanie bazy (backup) i jej odtwarzanie w przypadku ewentualnej awarii mają równie zasadnicze znaczenie. Większość dużych producentów systemów baz danych dostarcza własnych, inteligentnych systemów do składowania i odtwarzania bazy, rozwiązujących problemy nie spotykane przy składowaniu standardowych plików systemowych.

Na ogół składowanie bazy musi odbywać się w czasie jej działania. Pojawia się więc problem niezgodności danych w tabelach już zeskładowanych z dawną zawartością i modyfikowanych w bazie przez aktualne transakcje. Problem ten rozwiązuje się przez składowanie również pliku dziennika, w którym zapisuje się informacje o wszystkich dokonywanych transakcjach. Staranne używanie znaczników czasowych pozwala na odtworzenie zawartości bazy nawet po awarii sprzętowej lub programowej.

Również stosowanie pewnych rozwiązań sprzętowych, niezależnych od serwera bazy danych, takich jak dyski w konfiguracji RAID, podwójne zasilanie, UPS lub konfiguracje odporne na uszkodzenia (fault tolerant), daje zwiększoną ochronę danych.

Systemy transakcyjne a wspieranie decyzji

Obecnie coraz częściej korzysta się z danych systemu transakcyjnego do wspierania aplikacji podejmowania decyzji. Nie można jednak tych systemów łączyć, gdyż ich wymagania zasadniczo różnią się. Złożone zapytanie z aplikacji do wspierania decyzji jest w stanie całkowicie wstrzymać działanie systemu transakcyjnego, gdyż skanowanie wielu tabel spowoduje ich zablokowanie na dłuższy czas. Nawet jeśli metodami administracyjnymi wykluczy się takie zapytania, to i tak nie zaleca się pobierać danych do wspomagania decyzji podczas działania systemu transakcyjnego. Liczne i dobrze opracowane indeksy przyśpieszają działanie systemów wspierania decyzji, natomiast w systemach transakcyjnych dodanie kolejnego indeksu trzeba starannie przemyśleć, gdyż powoduje on spowolnienie każdej operacji zapisu do bazy.

Obecnie niektórzy producenci systemów do zarządzania bazami danych usiłują w jednym serwerze łączyć właściwości niezbędne dla systemu transakcyjnego i systemu wspierania decyzji. Ale i oni nie zalecają łączenia tych systemów, mimo możliwości stosowania potężnych komputerów masowo równoległych MPP.