Najczęściej zadawane pytania

Zobacz także

Podobnych informacji szukaj w najczęściej zadawanych pytaniach dotyczących aplikacji czytelnika i
najczęstszych problemach związanych z instalacją aplikacji czytelnika.

Czy dLibra może zostać zainstalowana na wirtualnym serwerze?

Nie ma żadnych przeciwwskazań technicznych by dLibra chodziła na maszynie wirtualnej. Należy tylko pamiętać, że w przypadku gdy dLibra będzie bardzo obciążać serwer (duża liczba nowych publikacji, spory ruch użytkowników www) konieczne może okazać się wydzielenie dedykowanej maszyny fizycznej.

Jak dotąd miał miejsce jeden przypadek gdy jedna z dużych bibliotek cyfrowych musiała zrezygnować z wirtualizacji, po przeniesieniu dLibry do systemu gospodarza wszystko chodziło dużo lepiej. Nie mniej w przypadku małej biblioteki cyfrowej i mocnej maszyny, wirtualizacja może być dobrym pomysłem na zutylizowanie mocy serwera.

Jak dotąd dLibra była instalowana na wirtualnych serwerach tworzonych w oparciu o oprogramowanie VMWare oraz na platformie s390x/zLinux firmy IBM.

Czy dLibra sama przeprowadza backup? Które pliki/foldery powinny zostać zabezpieczone?

dLibra nie ma wbudowanych żadnych kompleksowych mechanizmów związanych z tworzeniem kopii zapasowych. Wszelkie działania w tym zakresie powinna podjąć osoba administrująca serwerem biblioteki cyfrowej.

dLibra przechowuje dane w dwóch miejscach, pierwszym z nich jest relacyjna baza danych, a drugim system plików. Jeżeli chodzi o bazę danych to większość współczesnych systemów bazodanowych pozwala na łatwe stworzenie kopii zapasowej zawartości. Szczegółów związanych z przeprowadzeniem tej operacji należy szukać w dokumentacji konkretnego systemu bazodanowego.

Odrębną kwestią jest zabezpieczenie systemu plików. Załóżmy następującą strukturę instalacji systemu dLibra:

  • dlibra-webapp-5.0 - katalog z aplikacją czytelnika
  • dlibra-server-5.0 - katalog z serwerem dLibry
  • webapp-work - katalog roboczy aplikacji czytelnika
    • cache - ścieżka do tego katalogu określona jest w pliku dlibra-webapp-5.0/WEB-INF/conf/cache.properties
    • jcr - ścieżka do tego katalogu określona jest w pliku dlibra-webapp-5.0/WEB-INF/conf/jcr.properties
    • gossip - ścieżka do tego katalogu określona jest w pliku dlibra-webapp-5.0/WEB-INF/conf/gossip.properties
    • ..
  • content - katalog z plikami i indeksami wyszukiwawczymi
    • files - ścieżka do tego katalogu określona jest w pliku dlibra-server-5.0/conf/cs/service.properties w zmiennej contentDirectory
    • index - ścieżka do tego katalogu określona jest w pliku dlibra-server-5.0/conf/lucene.properties w zmiennej indexDirectory

Dane, które dLibra składuje poza bazą danych znajdują się w katalogach content/files i content/index. Katalog content zawiera wszystkie publikacje i ich pliki, katalog ten należy backupować we własnym zakresie - przed wykonaniem należy się upewnić, że nikt akurat nie dodaje nowych dokumentów do repozytorium.

Katalog content/index zawiera indeksy wyszukiwawcze. W przypadku utraty tych indeksów użytkownicy będą pozbawieni możliwości przeszukiwania zbiorów biblioteki cyfrowej. Tworząc kopie zapasową należy się upewnić, że serwer nie modyfikuje plików indeksów. Ponieważ jest to zadanie trudne w dLibre wbudowano mechanizm automatycznego tworzenia backupu indeksów. Kopia zapasowa jest tworzona domyślnie w katalogu index_backup w każdą niedzielę.

Istnieje również możliwość odtworzenia indeksów jednak indeksacja wszystkich zasobów wiąże się (w zależności od mocy maszyny i ilości oraz formatu plików publikacji) z długotrwałym obciążeniem serwera.

Oprócz wspomnianych powyżej katalogów należy również wykonać kopię katalogu webapp-work/jcr przechowywane są w nim ustawienia i treści wykorzystywane przez aplikację czytelnika.

Jak szybko usunąć wartości atrybutów, które nie zostały użyte w żadnym opisie?

Usuwanie nieużywanych wartości wybranych lub wszystkich atrybutów jest operacją zaawansowaną i obecnie nie jest dostępne z poziomu żadnej z aplikacji systemu dLibra. Możliwe jest jednak wykonanie takiej operacji bezpośrednio na bazie danych.

Należy pamiętać, że działanie takie jest niepożądane jeśli w bibliotece funkcjonuje słownik wartości atrybutów, które mogą być użyte w opisach publikacji dodawanych w przyszłości. Jest to często spotykana sytuacja w przypadku takich atrybutów jak Format, Typ czy Język.

  1. Operację czyszczenia słownika powinni wykonywać wyłącznie administratorzy serwerów dLibra ze znajomością obsługi systemów baz danych.
  2. Wszystkie operacje polegające na bezpośredniej modyfikacji bazy danych należy wykonywać po wyłączeniu systemu dLibra.
  3. Podstawową czynnością, którą należy wykonać przed przystąpieniem do przeprowadzenia operacji usuwania wartości jest zabezpieczenie danych biblioteki cyfrowej, a przede wszystkim wykonanie kopii zapasowej bazy danych.
  4. Opisane tu działanie wykonywane jest na własną odpowiedzialność osoby je wykonującej, a jego skutki nie mogą stanowić podstawy do zgłoszenia błędu w działaniu systemu dLibra.

Aby usunąć ze słownika nieużywane w opisach wartości należy wykonać następujące polecenie SQL:

  • W przypadku usuwania nieużywanych wartości ze wszystkich atrybutów:

    DELETE FROM MET_ATTRIBUTE_VALUES
    WHERE AV_ID NOT IN (SELECT EA_AV_ID FROM MET_EDI_ATTS
                        UNION
                        SELECT PA_AV_ID FROM MET_PUB_ATTS
                        UNION
                        SELECT DA_AV_ID FROM MET_DIR_ATTS
                        );
    
  • W przypadku usuwania nieużywanych wartości z pojedynczego atrybutu:
    1. Należy określić identyfikator atrybutu, którego słownik ma zostać wyczyszczony. Listę atrybutów można uzyskać następującym zapytaniem:

      SELECT ATT_ID, AD_NAME FROM MET_ATTRIBUTES, MET_ATTRIBUTE_DATAS, MET_LANGUAGES
      WHERE ATT_ID = AD_ATT_ID
      AND AD_LAN_ID = LAN_ID
      AND LAN_NAME = 'PL'
      AND (LAN_TYPE = 1 OR LAN_TYPE = 2)
      ORDER BY ATT_ID;
      
    2. Następnie należy wykonać właściwe zapytanie (poniżej), uprzednio wstawiając w miejsce <ATTR_ID> identyfikator atrybutu, którego słownik ma zostać wyczyszczony:

      DELETE FROM MET_ATTRIBUTE_VALUES
      WHERE AV_ID IN (SELECT D.AV_ID FROM MET_ATTRIBUTE_VALUES D
                      WHERE D.AV_ID NOT IN (SELECT EA_AV_ID FROM MET_EDI_ATTS, MET_ATTRIBUTE_VALUES A
                                            WHERE EA_AV_ID = A.AV_ID AND A.AV_ATT_ID = <ATTR_ID>
                                            UNION
                                            SELECT PA_AV_ID FROM MET_PUB_ATTS, MET_ATTRIBUTE_VALUES B
                                            WHERE PA_AV_ID = B.AV_ID AND B.AV_ATT_ID = <ATTR_ID>
                                            UNION
                                            SELECT DA_AV_ID FROM MET_DIR_ATTS, MET_ATTRIBUTE_VALUES C
                                            WHERE DA_AV_ID = C.AV_ID AND C.AV_ATT_ID = <ATTR_ID>
                                           )
      AND D.AV_ID NOT IN (SELECT DISTINCT AV_BAS_ID FROM MET_ATTRIBUTE_VALUES
      		    WHERE D.AV_ID = AV_BAS_ID
      		    AND AV_ID IN (SELECT EA_AV_ID FROM MET_EDI_ATTS, MET_ATTRIBUTE_VALUES E
      		                  WHERE EA_AV_ID = E.AV_ID AND E.AV_ATT_ID = <ATTR_ID>
      		                  UNION
      		                  SELECT PA_AV_ID FROM MET_PUB_ATTS, MET_ATTRIBUTE_VALUES F
      		                  WHERE PA_AV_ID = F.AV_ID AND F.AV_ATT_ID = <ATTR_ID>
      		                  UNION
      		                  SELECT DA_AV_ID FROM MET_DIR_ATTS, MET_ATTRIBUTE_VALUES G
      		                  WHERE DA_AV_ID = G.AV_ID AND G.AV_ATT_ID = <ATTR_ID>
      		                 )
                          )
      AND AV_ATT_ID = <ATTR_ID>);
      

Czas wykonania powyższych poleceń SQL może się wydłużać w zależności od ilości danych w tabelach biorących udział w danym zapytaniu.

Co zrobić, gdy kodowanie znaków w MySQL ustawione jest na UTF-8 a mimo to polskie znaki nie są wyświetlane poprawnie?

 

Sytuacja taka występuje niezmiernie rzadko. Do tej pory zaobserwowano ten problem tylko w przypadku jednej konfiguracji programowej będącej połączeniem systemu operacyjnego Ubuntu w wersji 64-bit z bazą danych MySQL 5.5.x. Problem dotyczy zarówno pierwszego uruchomienia po instalacji dLibry, podczas którego inicjowana jest baza danych jak i dalszego użytkowania dLibry. Rozwiązaniem jest dopisanie na końcu URL-a wykorzystywanego do połączenia z bazą danych poniższego parametru:

?characterEncoding=UTF-8

W przypadku serwera dLibry należy to zrobić w pliku database.properties znajdującym się w katalogu conf. W przypadku instalatora zmiany należy wprowadzić do pliku install-sql/mysql/mysql-db.properties.

  • No labels