Najlepszą praktyką jest ustawienie dla dwóch poniższych ustawień (CaseRetentionDays i VideoArchiveExpirationDays) tej samej wartości.

Ustawienie: Maintenance.CaseRetentionDays

Domyślnie: 30 dni

Gdy data aktualizacji sprawy jest starsza niż 30 dni (domyślnie), wszystkie dane sprawy są usuwane z bazy danych i dysku BriefCam .

Modyfikacje sprawy wpływają na datę jej aktualizacji, np. poprzez edycję nazwy lub opisu sprawy, udostępnienie sprawy, dodanie/usunięcie wideo, edycję harmonogramu wideo, edycję ustawień wstępnych lub dodanie/usunięcie zakładek. Jednak dodanie twarzy lub tablicy rejestracyjnej do listy ostrzegawczej sprawy lub edytowanie szczegółów zakładki nie wpłynie na datę aktualizacji sprawy.

Jeśli te same dane są używane przez inne sprawy, sprawa nadal będzie usunięta z ekranu spraw, a dane pozostaną w bazie danych i na dysku.

Jeśli sprawa zawiera aktywowane zaplanowane źródło, sprawa nie zostanie usunięta. Żądania z zaplanowanego źródła starsze niż wartość tego ustawienia będą usuwane, ale ich zakładki zostaną usunięte tylko po usunięciu całej sprawy. Jeśli sprawa zawiera również źródło, które nie jest aktywowanym źródłem zaplanowanym lub jest wyłączonym źródłem zaplanowanym, te źródła również nie zostaną usunięte.

Jeśli sprawa zawiera tylko źródła regularne lub wyłączone źródła zaplanowane, sprawa będzie traktowana jako źródło regularne, co oznacza, że gdy data aktualizacji sprawy jest starsza niż 30 dni (domyślnie), wszystkie dane sprawy starsze niż 30 dni (domyślnie) są usuwane z bazy danych i dysku BriefCam .

Gdy żądanie REVIEW jest częściowo oparte na przetwarzaniu na żądanie, a częściowo na żądaniu na żywo (ponieważ część żądania została już przetworzona w celu wyświetlenia alertu), artefakty są usuwane z modułów REVIEW i RESPOND zgodnie z ustawieniami konserwacji. Żądanie jest jednak całkowicie usuwane z infrastruktury (w tym z bazy danych) zgodnie z datą przetworzenia, która z tych dwóch dat miała miejsce ostatnio: przetwarzanie na żądanie lub przetwarzanie na żywo.

Jeśli chodzi o listy nadzoru, wewnętrzna lista nadzoru utworzona w ramach sprawy zostanie usunięta po usunięciu sprawy (przez konserwację lub użytkownika).

Jeśli chodzi o zakładki, zostaną one również usunięte po usunięciu sprawy, jak opisano powyżej.

Ustawienie: Maintenance.VideoArchiveExpirationDays

Domyślnie: 30 dni

To ustawienie określa, jak często mają być usuwane pliki wideo pobrane z systemu VMS. Ustawienie to ma również wpływ na pierwotny materiał wideo pobrany w ramach alertów systemu RESPOND, które zazwyczaj nie są BriefCam automatycznie (tylko po kliknięciu miniatury alertu). Przykładowo w module RESPOND oryginalny materiał wideo dla każdego alertu nie jest pobierany, dopóki użytkownik nie zażąda oryginalnego materiału wideo. Gdy użytkownik zażąda oryginalnego materiału wideo, BriefCam zachowuje oryginalny materiał wideo w celu uzyskania natychmiastowego dostępu przez liczbę dni określoną w tym parametrze.

Ustawienie: Maintenance.LocalFilesRetentionInHours

Domyślnie: 24 godziny

To ustawienie określa, jak często (w godzinach) z bazy danych BriefCam usuwane są renderowane pliki tymczasowe.

Tymczasowe pliki renderowane znajdują się w: ..\BriefCam\ServerData\VideoStreamingGateway\VideoService.

Pliki zapisane w tym miejscu są renderowanymi artefaktami utworzonymi w wyniku interakcji użytkownika z klientem sieci Web, takimi jak VIDEO SYNOPSIS, oryginalne wideo itp.

Ustawienie: Maintenance.RenderingUploadedFilesRetentionDays

Domyślnie: 0.5 dnia

To ustawienie określa, jak często przekazywane pliki są usuwane z bazy danych BriefCam .

Przesłane pliki znajdują się w: ..\BriefCam\ServerData\VideoData\WebUpload.

Pliki zapisywane w tym miejscu są plikami wideo wczytywanymi przez użytkownika końcowego za pośrednictwem klienta sieci Web w celu przetwarzania przez firmę REVIEW w Investigator, Investigator for TeamsProtecti konfiguracji.

Ustawienie: clientMaintenanceCaseMessageInDays

Domyślnie: 7 dni

To ustawienie określa, kiedy rozpocznie się wyświetlanie powiadomienia o usunięciu w sprawie. Ustawiona wartość to liczba dni, po upływie których sprawa ma zostać usunięta w procesie konserwacji.

Ustawienie:Maintenance.LiveRetentionDays

Domyślnie: 7 dni

Wszystkie alerty RESPOND spoza zakresu przechowywania zostaną usunięte (nawet alerty z zakładkami; jednak sama zakładka nie zostanie usunięta). Zakładki w module RESPOND nigdy nie są usuwane podczas konserwacji.

Alerty dla aktualnie uruchomionych zadań na żywo są usuwane, jeśli znajdują się poza zakresem przechowywania.

Ustawienie: Maintenance.BIAassetsRetentionDays

Domyślnie: 30 dni

To ustawienie określa, jak często tabele usługi RESEARCH BI (generowane z BriefCam metadanych ETL) są usuwane z BriefCam danych. To jest kopia zapasowa, jeśli firma Qlik nie była w stanie pobrać danych.

Ustawienie: Maintenance.BIVisualLayersRetentionDays

Domyślnie: 3650 dni

To ustawienie określa, jak często mają być usuwane pliki warstwy wizualnej używane na karcie Pulpit nawigacyjny. Spowoduje to usunięcie plików z bazy danych BriefCam oraz z folderu programu, w BriefCam są zapisywane obrazy (C:\BriefCam\ServerData\RenderData).

Ustawienie tej wartości na mniej niż 1 dzień może mieć wpływ na warstwy wizualne.

Ustawienie: Maintenance.BITaskRetentionDays

Domyślnie: 3 dni

To ustawienie określa, jak często metadane i zasoby wizualne z zadań przetwarzania programu RESEARCH są usuwane z magazynu BriefCam . Metadane to wszystkie zasoby/pliki/rekordy, które są tworzone podczas przetwarzania RESEARCH (ciągłego lub na żądanie). W ten sposób BriefCam zapisuje dane dla usługi aparatu reguł analizy biznesowej.

Ustawienie: RESEARCH.QVDRetentionDays

Domyślnie: 30 dni

To ustawienie określa liczbę dni, przez jaką zachowywane są szczegółowe tabele we wdrożeniach z podzielonymi QVD.

Ustawienie: RESEARCH.DetailedLoadDays

Domyślnie: 30 dni (w przypadku środowisk zaktualizowanych z wersji 6.4 lub nowszej, domyślnie 730 dni)

To ustawienie kontroluje dane ładowane z aplikacji RESEARCH (na podstawie pola znacznika czasu, a nie czasu VMS). To ustawienie wpływa na pamięć RAM wymaganą do załadowania szczegółowej aplikacji i zmniejsza ilość danych ładowanych do pełnego modelu danych.

To ustawienie nie ma wpływu na zagregowane tablice.

Poniższe elementy nie są usuwane podczas konserwacji.

Można monitorować i śledzić konserwację.

Konserwacja jest realizowana przez oddzielną usługę o nazwie: Serwis i posiada własny dziennik. Na ekranie zdarzeń można sprawdzić, czy usługa jest uruchomiona.

Jeśli konserwacja nie powiodła się, w przypadku osiągnięcia wartości progowych dla zdarzeń konserwacji na ekranie Zdarzenia (powyżej) pojawi się zdarzenie konserwacji. Domyślnie, jeśli konserwacja nie powiodła się co najmniej jeden raz, pojawi się zdarzenie ostrzegawcze, a jeśli konserwacja nie powiodła się trzy razy w ciągu ostatnich trzech lat, pojawi się zdarzenie krytyczne.

Ręczna konserwacja jest niezbędna w przypadku baz danych PostgreSQL, aby zapobiec problemom z wydajnością i wzdęciom tabeli. Okresowe uruchamianie operacji VACUUM FULL i REINDEX pomaga utrzymać wydajność i stabilność bazy danych. Aby uniknąć wpływu na dostępność bazy danych, należy planować te zadania w okresach niskiego wykorzystania lub planowanych okien konserwacji, najlepiej co kilka miesięcy lub pół roku. Zapewnia to płynne i efektywne działanie bazy danych.

W przypadku baz danych o rozmiarze folderu PostgreSQL_Data ~200GB wymagane jest okno konserwacji do 6 godzin raz na 6 miesięcy. W systemach o dużej aktywności czas konserwacji i przedział czasu odpowiednio się zwiększą.