Archiv pro štítek: sql

Doporučení pro velikosti databází pro System Center Operations Manager

nologo_600wbVýpočet – lépe řečeno odhad velikosti jednotlivých databází závisí na počtu sledovaných serverů, skladbě pravidel a monitorů, nastavení auditní politiky a samozřejmě na době uchování historických dat v konkrétní databázi. Dobré a bezpečné výsledky dává Operations Manager 2007 R2 – Sizing Helper, který vypracovala produkční skupina SCOM. Nejnovější verze System Center 2012 Operations Manager Sizing Helper Tool v1.xls  je sice z roku 2012, ale je stále dobrým výchozím nástrojem pro plánování i pro verzi 2012 R2. Tento nástroj je součástí balíčku System Center 2012 – Operations Manager Component Add – On, najdete jej jako poslední položku na seznamu obsažených souborů, samostatně zde.   Pro ACS je dobrým nástrojem ACS Database planning calculator od Secure Vantage Technologies.

Obecná doporučení pro databázi OperationsManager

Pokračování textu Doporučení pro velikosti databází pro System Center Operations Manager

Aktualizace pro MS SQL Server

Bill Graziano stále udržuje aktuální informace na stránce http://www.sqlteam.com/article/sql-server-versions:

I’m continually trying to track down what service packs are installed on various SQL Servers I support.  I can never find the right support page on Microsoft’s site.  So here’s an article with all the SQL Server version information I can track down.  If you know of any older versions or can help me fill out any missing data, please post in the comments and I’ll update the article.

Už jsem o této stránce psal před třemi lety (http://blogs.technet.com/b/jermar/archive/2009/03/25/verze-microsoft-sql-serveru-po-aktualizac-ch.aspx) a dnes opět musím ocenit snahu autora o přehledné a aktuální informace.

ACS: 42 dní a dost?

Pokud zvětšíme počet dní, po které jsou uchována data v databázi ACS na více než 42 (dní), zjistíme po čase nepříjemnou skutečnost. Starší data se v reportech nezobrazují. Kontrola přímo v databázi prozradí, že je vše v pořádku, je vytvořen požadovaný počet datových oddílů (partitions), ale pohledy používané v reportech (dvHeader, dvAll5, dvAll) nejstarší data nezobrazují.
V čem je problém?
V dynamické definici výše uvedených pohledů, jak se můžeme přesvědčit, když si v nástroji SQL Server Management Studio zobrazíme definici pohledu dvAll (Script View as | CREATE To | New Query Editor Window). Ve skriptu bude uvedeno spojení maximálně 42 dílčích pohledů dvAll_<uid> jednotlivých denních oddílů.

 

create view [AdtServer].[dvAll] as
   select * from dvAll_9c3313df_5146_4b30_ae0b_5c989adfb60d union all
   select * from dvAll_e8bfe379_2ef4_4ce8_a5c1_abc61f814798 union all
   select * from dvAll_46ea83f7_caa6_41c5_af65_2b505586e87f       -- a tak dále

Dá se to napravit?
Zatím jsem nikde neobjevil oficiální vyjádření Microsoftu, takže berte následující pokyny s rezervou.

Na serveru, který má roli ACS Collector jsou dva skripty v jazyce SQL: C:\WINDOWS\system32\Security\AdtServer\DbCreatePartition.sql a C:\WINDOWS\system32\Security\AdtServer\DbDeletePartition.sql.

V nich jsou definice s pevně určeným počtem datových oddílů databáze, číslem 42. Například pro pohled dvAll je v prvním skriptu uvedeno:

 

* Create or update dvAll, the view across all partition views
*
*************************************************************************/
 declare @iIsFirst int
 declare @vchStmt nvarchar(max)
 declare @vchPartitionId nchar(36)
 declare cPartition cursor for
   select top 42 PartitionId from dtPartition order by PartitionCloseTime desc

Ve zmíněných skriptech se číslo 42 nachází shodně ve všech třech definicích pohledů dvAll, dvAll5 i dvHeader.  Pokud požadujeme reporty z dat z většího časového úseku, musíme tuto konstantu na šesti místech zvětšit. Nezapomeňte oba původní skripty nejprve uložit v původním tvaru! Jakmile omylem změníte něco jiného, nebude správně fungovat noční údržba databáze. To jen pro jistotu, že existuje cesta zpět . . .

Zmínky o tomto „problému“ najdeme v diskuzních fórech:

http://systemcentersolutions.wordpress.com/2011/01/11/audit-collection-services-reports-only-show-the-last-42-days-worth-of-data/

Poznámka:
Na serveru SQL 2005 lze použít maximálně 255 partitions – důvodem je omezení počtu použitých výrazů „union all“ v definici pohledu v této verzi SQL serveru. SQL Server 2008 toto omezení nemá.

Audit Collection Service: struktura databáze

Struktura databáze OperationsManagerAC a organizace dat z pohledu databázového „laika“.

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í:

dtCategory seznam auditních kategorií
dtConfig konfigurace ACS, časové konstanty, počet datových oddílů
dtMachine seznam serverů, ze kterých se sbírají data
dtPartition seznam datových oddílů, informace o jejich stavu, ID
dtSource zdroje
dtType datové typy
— datové tabulky pro jeden oddíl:
dtEvent_1be83462_241e_45be_aaf4_a7a9cf603b09 v názvu je ID příslušného oddílu
dtEventData_1be83462_241e_45be_aaf4_a7a9cf603b09
dtPrincipal_1be83462_241e_45be_aaf4_a7a9cf603b09
dtString_1be83462_241e_45be_aaf4_a7a9cf603b09
— (data ostatních oddílů – partitions)

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

 

Audit Collection Service: jak na historická data?

V databázi ACS systému SCOM 2007 jsou udržovány záznamy po dobu, kterou definujeme podle konkrétního prostředí, ve kterém je sběr auditních záznamů implementován. Výchozí nastavení představuje období předchozích 14 dní + aktuální den. Podle počtu agentů, nastavení auditní politiky na nich a pochopitelně v závislosti na výkonu databázového serveru, můžeme toto období protáhnout na 30, 100 nebo 300 dní. Hranice použitelnosti výsledné databáze ve vztahu k pokrytému období je tedy různá, stejně jako požadavky na uchování historických záznamů a možnost jejich zpracování a liší se případ od případu.

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.

Powershell a jednoduchý dotaz do databáze

Před časem jsem zkoušel pomocí příkazového řádku Command  Shell v systému Operations Manager 2007 zjistit podrobnosti k definicím alertů a zjistil jsem, že nejjednodušší cestou bude číst informaci přímo z databáze OperationsManager. Jak se jednoduše připojit k databázím? Následující příklad ukazuje nejprve dva dotazy do databáze ACS, tj. OperationsManagerAC a třetí dotaz je směrován do databáze OperationsManager. Pomocí prostředků .Net definujeme dotaz, připojení, kanál a datovou sadu. Jakmile se úspěšně připojíme, můžeme získaná data zpracovat:

$query= "SELECT * FROM [OperationsManagerAC].[dbo].[dtConfig]"
$connection = "server=SCOM07;trusted_connection=true;database=OperationsManagerAC"
$set = New-Object "System.Data.Dataset" "myData"
$channel = New-Object "System.Data.SQLclient.SQLdataAdapter" ($query,$connection)
$channel.fill($set)
$set.tables | fl 

#### druhy dotaz
$query2= "SELECT * FROM [OperationsManagerAC].[dbo].[dtMachine]"
$set2 = New-Object "System.Data.Dataset" "myData2"
$channel2 = New-Object "System.Data.SQLclient.SQLdataAdapter" ($query2,$connection)
$channel2.fill($set2)
$set2.tables | fl 

#### treti dotaz
$query3 = "SELECT top 10 [RuleModuleId]
      ,[RuleModuleName]
      ,[RuleModuleRole]
      ,[ModuleTypeId]
      ,[RuleId]
      ,[TargetTypeId]
      ,[RuleModuleConfiguration]
      ,[RuleModuleOrder]
  FROM [OperationsManager].[dbo].[RuleModule]"
$connection3 = "server=SCOM07;trusted_connection=true;database=OperationsManager"
$set3 = New-Object "System.Data.Dataset" "myData3"
$channel3 = New-Object "System.Data.SQLclient.SQLdataAdapter" ($query3,$connection3)
$channel3.fill($set3)
$set3.tables | fl rulemoduleconfiguration

Výpis výstupů všech tří dotazů následuje:

1) nejprve kofigurace ACS:


Id      : 1
Value   : 1
Comment : convert timestamps to local time

Id      : 2
Value   : 6
Comment : database schema version

Id      : 3
Value   : 1
Comment : perform index maintenance

Id      : 4
Value   : 0
Comment : table switch offset in seconds since midnight UTC

Id      : 5
Value   : 86400
Comment : table switch interval in seconds

Id      : 6
Value   : 15
Comment : number of partitions

2) seznam serverů (forwarders) ACS:


Id                : 0
CreationTime      : 9.8.2010 15:38:25
Sid               : S-1-5-21-1056727167-2314404654-873565541-1103
Description       : TRIAL\SCOM07$
DistinguishedName : CN=SCOM07,CN=Computers,DC=trial,DC=net

Id                : 1
CreationTime      : 20.8.2010 22:10:24
Sid               : S-1-5-21-1056727167-2314404654-873565541-1000
Description       : TRIAL\DC01$
DistinguishedName : CN=DC01,OU=Domain Controllers,DC=trial,DC=net

3) výpis z konfigurace pravidel:

RuleModuleConfiguration : <Query>select sum(HitCount), SourceEntityId from AemC
                          rashCounters AC join MT_WatsonBucket WB on AC.SourceE
                          ntityId = WB.BaseManagedEntityId where EntityTypeId =
                           1 group by SourceEntityId</Query><ObjectName>Bucket<
                          /ObjectName><CounterName>BucketErrorCount</CounterNam
                          e><Value>Columns/Column[1]</Value><ManagedEntityId>Co
                          lumns/Column[2]</ManagedEntityId><RuleId>$MPElement[N
                          ame="AEMViewsInternal!Microsoft.SystemCenter.CM.AEM.V
                          iews.Internal.BucketTotalHitCountPerfCollector"]$</Ru
                          leId>

RuleModuleConfiguration : <Scheduler><SimpleReccuringSchedule><Interval Unit="M
                          inutes">15</Interval></SimpleReccuringSchedule><Exclu
                          deDates/></Scheduler>

.