Wpisy z tagiem: dba4dev

Gdzie powinny być przechowywane pliki binarne użytkowników twojej aplikacji ? W systemie operacyjnym czy bazie danych ?

Jeśli użytkownicy twojej aplikacji mają przechowywać pliki - np. dokumenty w formacie pdf lub skany, zdjęcia, dźwięki czy filmy - to gdzie najlepiej będzie je magazynować ? Czy będzie to baza danych z możliwością przechowywania BLOB'ów ? Czy raczej katalog w systemie operacyjnym, a w bazie danych będzie przechowywana jedynie ścieżka do pliku i metadane ? Co decyduje o wyborze jednego z tych rozwiązań ?

Gdy powstawały relacyjne bazy danych u ich podstaw legła potrzeba przechowywania dużej ilości danych w małych porcjach i w określonym porządku. Podczas gdy systemy plików zostały zaprojektowane do przechowywania danych w dużych porcjach i bez określonego porządku. Gdzie obecnie leży granica wielkości pliku, za którą baza danych lub system plików będzie lepszym rozwiązaniem ?

Oto lista czynników wartych rozważenia:

• łatwość implementacji - jakimi kompetencjami i narzędziami dysponuje zespół tworzący aplikację
• prostota zarządzania i defragmentacji - jak często i jakim kosztem można przenosić i defragmentować dane
• wydajność - które z rozwiązań pozwala na wydajniejszy zapis/modyfikację i odczyt danych. Czy pozwala na modyfikację fragmentu pliku/BLOB'a czy zawsze nadpisuje całość ?
• synchronizacja - jakie rozwiązanie trzeba zastosować aby mieć spójny bekap i możliwość odtworzenia plików/BLOB'ów zsynchronizowanych z metadanymi
• bezpieczeństwo - inny system przywilejów w systemie operacyjnym i bazie danych
• transakcyjność - zapis pliku w bazie danych jest fragmentem transakcji natomiast zapis w systemie operacyjnym nie jest transakcją
• pliki w bazie danych są bezpieczne przed wirusami - są zapisane w wewnętrznych strukturach bazy danych bez bezpośredniego dostępu dla innych procesów systemu operacyjnego
• dzielenie ogromnych plików (np. wideo) na mniejsze, łatwiejsze w zarządzaniu kawałki
• scalanie dużej ilości maleńkich plików w archiwa, np. TAR lub ZIP
• odporność na uszkodzenia, np. pad systemu - większość systemów plików zabepiecza jedynie swoje wewnętrzne struktury, a nie zawartość plików podczas gdy baza danych skupia się na zabezpieczeniu danych
• zapis danych - systemy plików i systemy operacyjne dostosowują kolejność zapisu bloków pliku aby zwiększyć wydajność - nie zapisują sekwencyjnie. Natomiast baza danych grupuje zmiany w blokach aby zapisywać ich większe porcje razem - zapisuje sekwencyjnie.
• replikacja - jak spójnie replikować system plików i metadane z bazy danych, np. na potrzeby wysokiej dostępności lub do systemu testowego ?
• skalowalność - setki tysięcy, miliony czy nawet miliardy rekordów w pojedynczej tabeli (szczególnie spartycjonowanej) nie są wyzwaniem dla bazy danych, podczas gdy dziesiątki tysięcy plików w systemie plików są trudne do obsłużenia dla systemu operacyjnego
• audyt - bazy danych mają wbudowane narzędzia do audytu - kiedy i w jaki sposób uzyskano dostęp do konkretnego BLOB'a

A może trzecia opcja: trzymanie najczęściej wykorzytywanych BLOB'ów w systemie operacyjnym jako pliki + ich wzorzec w bazie danych, jest najbardziej optymalna ?

#oracle #database #mysql #postgresql #sqlserver #sql #BLOB #dba4dev #marcinbadtke

Skończyła ci się kiedyś wolna przestrzeń we FRA ?

Poniżej 5 sposobów na poradzenie sobie z tą sytuacją.

Doświadczeni administratorzy baz danych mówią: gdy zapcha ci się FRA to albo twoja polityka retencji plików powinna zostać dostosowana, albo przestrzeń dyskowa przeznaczona na FRA powiększona. A może istnieje trzecia możliwość ?

FRA - Fast Recovery Area - przestrzeń dyskowa, automatycznie zarządzana przez Oracle, przeznaczona do przechowywania wszystkich plików potrzebnych do recovery bazy danych. Głównym celem istnienia FRA jest zminimalizowanie czasu potrzebnego na odzyskanie przez bazę danych pełnej sprawności po awarii poprzez gromadzenie, w jednym miejscu, wszystkich niezbędnych do naprawy bazy danych plików. Gdy we FRA kończy się wolna przestrzeń zazwyczaj oznacza to, że baza danych Oracle nie będzie miała gdzie zapisać archiwalnych plików dziennika powtórzeń i się zatrzyma.

Rodzaje plików przechowywanych we FRA:

• archived redo log - archiwalne pliki dziennika powtórzeń
• control file - kopia pliku kontrolnego
• control file autobackup - automatyczny bekap pliku kontrolnego
• flashback log - logi funkcji flashback
• redo log - jedna kopia każdego członka grupy redo
• RMAN datafile - kopie plików bazodanowych wykonanych przez RMAN'a
• RMAN backup piece - pliki bekapu wykonanego przez RMAN'a (więcej o backup piece: )

Gdy we FRA kończy się wolna przestrzeń masz następujące 5 opcji:

1. Zwiększyć wartość parameteru DB_RECOVERY_FILE_DEST_SIZE. Jeśli wolna przestrzeń dostępna jest na dysku to natychmiast zostanie dodana do FRA. Więcej o parametrze: https://docs.oracle.com/database/121/REFRN/GUID-FA2F9735-DD0E-4026-96F0-80AF0E5E6E64.htm#REFRN10235
2. Powiększyć fizyczną przestrzeń dyskową przeznaczoną dla FRA.
3. Przenieść FRA na inne dyski z większą ilością wolnej przestrzeni.
4. Wykorzystać komendę RMAN'a 'backup recovery area' aby przenieść zawartość FRA do innej przestrzeni.
5. Manualnie usunąć, z FRA, pliki, które nie są potrzebne, a następnie uspójnić repozytorium RMAN'a. Jest to możliwość ostateczna. Tzw. brzytwa dla tonącego.

Co sądzisz o przedstawionych pięciu opcjach ? Może znasz szóstą ?

#oracle #database #FRA #dba4dev #marcinbadtke