Návrh databáze využívá datové oddíly, dynamicky vytvářené a obsahující data za 24 hodin. Jeden den je tudíž základní jednotka, pokud počítáme s uchováním dat v databázi za delší období, vždy jsou to násobky celých dní. V databázi jsou vytvořené konfigurační tabulky a pro každý denní datový oddíl sada tabulek s datovými záznamy. Viz příklad z testovacího prostředí:

Pohledy (Views) jsou ve třech formátech, podle počtu zobrazovaných sloupců String01,  …, String22: dvHeader (pouze hlavička), dvAll5 (prvních pět sloupců), dvAll (všech 22 sloupců). Z následujícího předpisu pro kompletní pohled pouze pro jednu partition,  dvAll_5a1aa04b_b193_49b1_80ae_f3b019a404a3 je zřejmé, že doba zpracování dotazů v databázi bude nejkratší, pokud použijeme hledání v pohledech dvHeader. Je důležité si uvědomit, že pohled dvAll přes celou databázi představuje spojení všech existujících pohledů dvAll_<ID> přes všechny datové oddíly (partitions)


create view [dbo].[dvAll_5a1aa04b_b193_49b1_80ae_f3b019a404a3]
as
select
e.Id,
e.EventNo as EventId,
e.SequenceNo as SequenceNo,
'S/F' =
case e.TypeNo
when 8 then 'S'
when 16 then 'F'
else '?'
end,
c.Description as Category,
e.CreationTime as CreationTime,
e.CollectionTime as CollectionTime,
m.Description as AgentMachine,
sm.Description as EventMachine,
s.SourceName as Source,
p1.strSid as HeaderSid,
p1.strUser as HeaderUser,
p1.strDomain as HeaderDomain,
p2.strSid as PrimarySid,
p2.strUser as PrimaryUser,
p2.strDomain as PrimaryDomain,
e.PrimaryUserLogonId as PrimaryLogonId,
p3.strSid as ClientSid,
p3.strUser as ClientUser,
p3.strDomain as ClientDomain,
e.ClientUserLogonId as ClientLogonId,
p4.strSid as TargetSid,
p4.strUser as TargetUser,
p4.strDomain as TargetDomain,
s01.Description as String01,
s02.Description as String02,
s03.Description as String03,
s04.Description as String04,
s05.Description as String05,
s06.Description as String06,
s07.Description as String07,
s08.Description as String08,
s09.Description as String09,
s10.Description as String10,
s11.Description as String11,
s12.Description as String12,
s13.Description as String13,
s14.Description as String14,
s15.Description as String15,
s16.Description as String16,
s17.Description as String17,
s18.Description as String18,
s19.Description as String19,
s20.Description as String20,
s21.Description as String21,
s22.Description as String22
from
dtEvent_5a1aa04b_b193_49b1_80ae_f3b019a404a3 e
left outer join dtCategory c on e.CategoryNo = c.Id
left outer join dtMachine m on e.AgentMachineId = m.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 sm on e.EventMachineId = sm.Id
left outer join dtSource s on e.SourceId = s.Id
left outer join dtPrincipal_5a1aa04b_b193_49b1_80ae_f3b019a404a3 p1 on e.UserId = p1.Id
left outer join dtPrincipal_5a1aa04b_b193_49b1_80ae_f3b019a404a3 p2 on e.PrimaryUserId = p2.Id
left outer join dtPrincipal_5a1aa04b_b193_49b1_80ae_f3b019a404a3 p3 on e.ClientUserId = p3.Id
left outer join dtPrincipal_5a1aa04b_b193_49b1_80ae_f3b019a404a3 p4 on e.TargetUserId = p4.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s01 on e.StringId01 = s01.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s02 on e.StringId02 = s02.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s03 on e.StringId03 = s03.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s04 on e.StringId04 = s04.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s05 on e.StringId05 = s05.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s06 on e.StringId06 = s06.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s07 on e.StringId07 = s07.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s08 on e.StringId08 = s08.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s09 on e.StringId09 = s09.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s10 on e.StringId10 = s10.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s11 on e.StringId11 = s11.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s12 on e.StringId12 = s12.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s13 on e.StringId13 = s13.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s14 on e.StringId14 = s14.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s15 on e.StringId15 = s15.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s16 on e.StringId16 = s16.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s17 on e.StringId17 = s17.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s18 on e.StringId18 = s18.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s19 on e.StringId19 = s19.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s20 on e.StringId20 = s20.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s21 on e.StringId21 = s21.Id
left outer join dtString_5a1aa04b_b193_49b1_80ae_f3b019a404a3 s22 on e.StringId22 = s22.Id


Standardní implementace SCOM + ACS tuto oblast nepokrývá, ale je k dispozici placené řešení od SecureVantage Technologies (Archiver). Nic nám však nebrání, abychom si zpřístupnili historická data sami v paralelní databázi se stejnou strukturou, jakou má databáze se „živými daty“.

Výchozí modelová situace:

Aktuální data pokrývají období 100 dnů v provozní databázi ACS, historická data jsou k dispozici v archivních souborech a každý z nich pokrývá 100 dnů, se vzájemným přesahem 1-2 dny. Archivní soubory jsou vytvořené pomocí nástroje MS SQL Server Management Studio.  (Databases \ OperationsManagerAC | Tasks | Backup… | Backup type: Full | Back up to Disk: <jméno souboru>.bak)

Vytvoření prázdné databáze:

Databáze se bude jmenovat OperationsManagerACH, bude pro zjednodušení na stejném serveru SQL jako aktuální databáze – proto odlišné jméno. Na tomto serveru jsou také instalované SQL Reporting Services.

1. Získáme předpis pro vytvoření nové databáze: SQL Server Management Studio | označíme databázi OperationsManagerAC | Script Database as | CREATE To | New Query Editor Window
2. V editoru skript upravíme:
   jméno databáze, ctrl-H, Find what: OperationsManagerAC, Replace with: OperationsManagerACH
   jména souborů změníme, protože je ukládám do stejné složky:
   dbAuditData.mdf -> dbAuditDataH.mdf
   dbAuditLog.ldf -> dbAuditLogH.ldf
3. Skript provedeme (execute) a získáme tak novou prázdnou databázi OperationsManagerACH.

Zápis záznamů z archivu databáze:

Databázi OperationsManagerACH naplníme informacemi z archivního souboru, například v prostředí SQL Server Management Studio následujícím postupem.

Tasks | Restore | Database … | záložka (General)

• To database: OperationsManagerACH
• přepnout volbu na From device, vyhledáme [...] v dialogu Specify Backup: Backup media: File, Add : <jméno souboru.bak> OK,
• Označit Restore [x]

na druhé záložce (Options): označené jsou pouze dvě volby

• Restore options: Overwrite the existing database (WITH REPLACE) a
• Prompt before restoring each backup

Důležité je v tomto modelovém případě pozměnit pojmenování cílových souborů databáze historických dat:

• Restore the database files as (změnit pojmenování ve sloupci Restore As, [...]) <cesta>\dbAuditDataH.mdf a <cesta>\dbAuditLogH.ldf
• Dále zvolíme první položku Recovery state: Leave the database ready to use … (RESTORE WITH RECOVERY)

Jakmile akce Restore doběhne, jsou historická data plně k dispozici a lze je zpřístupnit pro reporty.

Reporty, Data Source:

Spustíme webový Report Manager a vytvoříme nový datový zdroj, který se připojuje k výše vytvořené databázi:

http://<reportserverMachine>/Reports

• akce Add new data source
• pojmenujeme – Name: DBH Audit
• povolíme – Enable this data source
• Definujeme způsob připojení databáze – Connection string: data source=<scom07serverName>;initial catalog=OperationsManagerACH;Integrated Security=SSPI
• Windows Integrated Security

Toť vše, protože je nová databáze vytvořena na serveru, kde je definována a korektně obsazena role db_datareader a jsou zde funkční SQL Reporting Services.