Underhåll och datalagring
För att upprätthålla helt optimerad BriefCam systemprestanda rensar BriefCam automatiskt bearbetade data regelbundet, inklusive data från både databasen och lagringen.
Observera att underhållstjänsten kan installeras på flera instanser för att fördela belastningen mellan flera datorer.
För att stänga av det automatiska underhållet, ange inställningen Maintenance.Enabled environment till false. Detta rekommenderas dock inte eftersom lagringen kommer att ta slut.
I miljöinställningen Maintenance.ExecutionStrategy kan underhållet ställas in att köras antingen dagligen eller kontinuerligt.
När inställningen är Kontinuerlig (standard) körs underhållet varje timme.
När inställningen är Dagligen, anges tiden den körs i miljöinställningen Maintenance.CleanHour. Värdet är tidsbaserat (hh:mm:ss), till exempel: 23:00:00.
För att rensa data proaktivt, ställ in miljöinställningen Maintenance.CleanHour till aktuell timme och ställ in Maintenance.ExecutionStrategy till Daily och starta sedan om Maintenance-tjänsten. Underhållet körs sedan omedelbart. Det rekommenderas att sedan ändra tillbaka inställningarna till deras originalvärde.
Om underhållet inte lyckas, försöker systemet automatiskt att återhämta sig när processen är igång. Försöket att återställa kommer att ske inom ett tidsintervall som konfigureras i inställningen TaskRecovery.IntervalsMinutes (som visas i bilden nedan). Standardvärdena är 10, 240 och 1440 minuter, vilket innebär att det första återställningsförsöket görs efter 10 minuter, det andra efter 4 timmar och det sista försöket efter 12 timmar.
Miljöinställningen Maintenance.ServiceInstancesRetentionMinutes avgör hur länge tjänsterna raderas från BriefCam databasen efter att de har gått offline. Standardvärdet är 43 200 minuter (30 dagar).
Sektionerna nedan beskriver ytterligare miljöinställningar som kontrollerar hur underhållsprocessen fungerar.
REVIEW-modul
Notera
Om det finns REVIEW-fall som du inte vill radera under det automatiska underhållet, klicka på ikonen redigera (
) på ärendets skärm och markera kryssrutan Radera inte under underhåll. Dessa markerade ärenden och deras artefakter kommer inte att raderas via underhållsprocessen även om andra ärenden eller larm använder den och raderas.
Bästa praxis är att ange samma värde för de två inställningarna nedan (CaseRetentionDays och VideoArchiveExpirationDays).
Inställning: Maintenance.CaseRetentionDays
Standard: 30 dagar
När ärendets uppdateringsdatum är äldre än 30 dagar (som standard) raderas alla data i ärendet från BriefCam databasen och disken.
Ändringar av ett ärende påverkar ärendets uppdateringsdatum, såsom att redigera ärendets namn eller beskrivning, dela ärendet, lägga till/radera videor, redigera videoschemaläggning, redigera förinställningar eller lägga till/radera bokmärken. Att lägga till ett ansikte eller en registreringsskylt till ärendets bevakningslista eller redigera bokmärkesinformation påverkar dock inte ärendets uppdateringsdatum.
Om samma data används av andra fall tas ärendet fortfarande bort från skärmen Ärenden och data behålls på databasen och disken.
Om ärendet innehåller en aktiverad schemalagd källa kommer ärendet inte att raderas. Förfrågningar från den schemalagda källan som är äldre än värdet i den här inställningen kommer att raderas, men deras bokmärken kommer bara att raderas när hela ärendet raderas. Om ärendet även innehåller en källa som inte är en aktiverad schemalagd källa eller är en inaktiverad schemalagd källa kommer inte heller dessa källor att raderas.
Om ärendet bara innehåller reguljära källor eller inaktiverade schemalagda källor, behandlas ärendet som en reguljär källa, vilket innebär att när ärendets uppdateringsdatum är äldre än 30 dagar (som standard), raderas alla data i ärendet som är äldre än 30 dagar (som standard) från BriefCam databasen och disken.
När REVIEW-begäran delvis baseras på bearbetning på begäran och delvis på live-begäran (eftersom en del av begäran redan behandlats för en avisering), tas artefakterna bort från REVIEW- och RESPOND-modulen enligt underhållsinställningarna. Begäran tas dock helt bort från infrastrukturen (inklusive databasen) enligt behandlingsdatumet för det av de två som hände sist: behovsstyrd behandling eller live-behandling.
Beträffande bevakningslistor kommer en intern bevakningslista som skapades i ett ärende att raderas så snart ärendet raderats (av underhåll eller av användaren).
När det gäller bokmärken kommer de även att raderas så snart ärendet raderats enligt ovan.
Inställning: Maintenance.VideoArchiveExpirationDays
Standard: 30 dagar
Denna inställning kontrollerar hur ofta videofiler som hämtats från VMS ska raderas. Den här inställningen påverkar även originalvideo som hämtades i RESPOND-aviseringar, som vanligtvis inte visas BriefCam automatiskt (bara när du klickar på aviseringens miniatyrbild). Till exempel, i RESPOND-modulen, hämtas inte originalvideon för varje avisering förrän användaren begär en originalvideo. När användaren begär en originalvideo, BriefCam behåller originalvideon för omedelbar tillgång under det antal dagar som anges i denna parameter.
Inställning: Maintenance.LocalFilesRetentionInHours
Standard: 24 timmar
Denna inställning kontrollerar hur ofta (i timmar) temporära renderade filer raderas från BriefCam databasen.
De temporära renderade filerna finns på: ..\BriefCam\ServerData\VideoStreamingGateway\VideoService.
Filerna som sparas här är renderade artefakter skapade av användarinteraktioner i webbklienten, som VIDEO SYNOPSISoriginalvideo och mer.
Inställning: Maintenance.RenderingUploadedFilesRetentionDays
Standard: 0,5 dagar
Denna inställning kontrollerar hur ofta uppladdade filer raderas från BriefCam databasen.
De uppladdade filerna finns på: ..\BriefCam\ServerData\VideoData\WebUpload.
Filerna som sparas här är videofiler som laddas upp av slutanvändaren via webbklienten för att REVIEW ska kunna behandla dem i Investigator, Investigator for Teams, Protect och konfigurationer.
Inställning: clientMaintenanceCaseMessageInDays
Standard: 7 dagar
Den här inställningen kontrollerar när borttagningsmeddelandet ska börja visas för ett ärende. Värdet som anges här är antalet dagar innan ärendet är inställt på att raderas av underhållsprocessen.
Observera
Dessa inställningar gäller inte för Hub. Det är endast relevant för platser och i fristående distributioner.
RESPOND-modul
Inställning:Maintenance.LiveRetentionDays
Standard: 7 dagar
Alla RESPOND-aviseringar utanför lagringsintervallet raderas (även aviseringar som är bokmärkta, men själva bokmärket raderas inte). Bokmärken i RESPOND-modulen raderas aldrig av underhållsprocessen.
Larm för aktiva live-aktiviteter raderas om de ligger utanför lagringsintervallet.
RESEARCH-modul
Inställning: Maintenance.BIAsetsRetentionDays
Standard: 30 dagar
Den här inställningen kontrollerar hur ofta RESEARCH BI-tabeller (skapade från BriefCam metadata-ETL) raderas från BriefCam lagringen. Detta är en säkerhetskopia om Qlik inte kunde hämta denna data.
Inställning: Maintenance.BIVisualLayersRetentionDays
Standard: 3650 dagar
Den här inställningen kontrollerar hur ofta du tar bort Visual Layer-filer som används för fliken Instrumentpanel. Detta raderar filerna från BriefCam databasen och från BriefCam mappen där bilderna sparas (C:\BriefCam\ServerData\RenderData).
Inställning av detta till mindre än 1 dag kan påverka de visuella lagren.
Inställning: Maintenance.BITaskRetentionDays
Standard: 3 dagar
Den här inställningen kontrollerar hur ofta metadata och visuella tillgångar från RESEARCH bearbetningsaktiviteter raderas från BriefCam lagringen. Metadata är alla tillgångar/filer/poster som skapas under RESEARCH-bearbetningen (antingen kontinuerlig eller på begäran). Så här länge BriefCam sparas data för BI Rule Engine-tjänsten.
Inställning: RESEARCH.QVDRetentionDays
Standard: 30 dagar
Den här inställningen avgör hur många dagar de detaljerade tabellerna i distributioner med delade QVD:er behålls.
Inställning: RESEARCH.DetailedLoadDays
Standard: 30 dagar (för miljöer som uppdaterats från v6.4 eller lägre är standard 730 dagar)
Den här inställningen kontrollerar inläst data från RESEARCH-appen (baserat på tidsstämpelfältet och inte på VMS-tid). Denna inställning påverkar det RAM-minne som krävs för att ladda den detaljerade appen och minskar mängden data som laddas till den fullständiga datamodellen.
De aggregerade instrumentpanelerna påverkas inte av denna inställning.
Bevakningslistflikar
En extern bevakningslista (hanterad i fliken Bevakningslista) raderas inte av underhållsprocessen. Som nämnts ovan kommer dock en intern bevakningslista som skapades i ett ärende att raderas så snart ärendet raderats (av underhåll eller av användaren).
Observera
Denna funktionalitet är inte applicerbar för Hub. Det är endast relevant för platser och i fristående distributioner.
Underhållsundantag
Följande objekt raderas inte under underhåll.
Mappen Bakgrundsbilder för kamera - När du använder Testa anslutning sparas en bild från kameran under
Camera Background Imagesmappen. Varje kamera underhåller en bild som uppdateras när anslutningen testas på nytt. Denna mapp och dess innehåll påverkas inte av underhåll.Bokmärken - Bokmärken skapade i RESPOND- eller REVIEW-moduler behålls i systemet även om den ursprungliga aviseringen eller objektet raderas. De tas bara bort när de uttryckligen raderas av användaren.
Ärenden märkta Radera inte under underhåll - I REVIEW-modulen kan du redigera ett ärende och markera kryssrutan Radera inte under underhåll. Dessa fall och deras associerade artefakter kommer att kvarstå under underhållscykler.
QVD-filer (RESEARCH Module) - QVD-filer är inte del av underhållsprocessen och måste raderas manuellt om det krävs.
Underhållsövervakning
Du kan övervaka och spåra underhållet.
Underhållet utförs av en separat tjänst kallad: Maintenance Service och har en egen logg. På skärmen Händelse kan du se om tjänsten körs.
Om underhållet misslyckades visas en underhållshändelse på skärmen Händelser (ovan) om tröskelvärdena för underhållshändelser uppnås. Som standard, om underhållet misslyckades med att köra minst en gång, visas en varningshändelse och om underhållet misslyckades de senaste tre gångerna visas en kritisk händelse.
PostgreSQL Manuellt underhåll
Manuellt underhåll är viktigt för PostgreSQL-databaser för att förhindra prestandaproblem och tabelluppblåsning. Regelbunden körning av VAKUUMFULL och REINDEX hjälper till att upprätthålla databasens prestanda och stabilitet. För att undvika att påverka databasens tillgänglighet, schemalägg dessa uppgifter under perioder med låg användning eller planerade underhållsfönster, helst med några månaders eller ett halvt års mellanrum. Detta säkerställer en smidig och effektiv databasdrift.
För databaser med en PostgreSQL_Data mappstorlek på ~200 GB krävs ett underhållsfönster på upp till 6 timmar en gång var sjätte månad. I system med hög aktivitet kommer tidsfönstret och intervallet för underhåll att öka i enlighet med detta.