Túlcsordulás... Vajon 10 OLAP tanácsadóból hány futott már bele?


Jelenleg egy adattárházat auditálok és sok minden más tesztelése mellett leellenőrzöm azt is, hogy helyesen lettek-e megválasztva az OLAP kockák measure-einek adattípusai.

A measures-ök adattípusának helyes megválasztása egyrészről a teljesítmény szempontjából fontos, - de erről már érintőlegesen beszéltem a legutolsó Technet szemináriumon - másrészről, ha túl kicsinek választjuk meg őket, akkor túlcsordulhatnak.

Mutatok egy példát. Tegyük fel, hogy a fact táblánk Measure oszlopa int típusú és két sort tartalmaz:

  • 1. sor: 2147483647 (Az int felső határa)
  • 2. sor: 1

A kocka felösszegzése után azt várnánk, hogy a kockában megjelenő totál összeg 2147483648 lesz. Ehelyett a kockában azt fogjuk látni, hogy mínusz 2147483549.

Hogyan lehetséges mindez? Úgy hogy az OLAP kockánk measure-ének adattípusát a ténytábla adattípusa után int-nek deklaráltuk és a measure egész egyszerűen túlcsordult.

Mutatom máshogy. Képzeljük el, hogy a ténytábla 2 sort tartalmaz:

  • 1. Sor: 2 milliárd
  • 2. Sor: 2 milliárd

Felösszegzés után 4 milliárdot várnánk, de ehelyett kb. -295 milliót kapunk. Az történ ugyanis, hogy a 4 milliárdból belerakott az Analysis Services az Int mezőbe annyit amennyit bírt (2147483647-et) majd a maradékot folytatta az int alsó határától: -2147483647-tól. így kaptunk -294967196-ot.

Megoldás: Az OLAP kockák measure-einek adattípusát nem a ténytábla adattípusa szerint kell megválasztanunk, hanem az alapján, hogy mekkora értékek lesznek benne felösszegzés után! Esetünkben, ha int helyett bigint-nek választottuk volna a measures adattípusát, akkor a helyes 4 milliárdos értéket kaptuk volna. A ténytábla adattípusa tehát csak a legkisebb választható adattípust jelöli ki!

Hogy ellenőrizhetjük, hogy helyesen lettek megválasztva az adattípusok?

Kezdjük a legegyszerűbb esettel: measure-ünk

  • Sum felösszegzési mód szerint legyen felösszegezve és
  • minden dimenziója tartalmazza az All elemet és
  • a measure-ön ne legyen definiálva MeasureExpression

Ebben az esetben a "Select Sum(Measure) from Ténytábla" SQL Select eredményeképp kapott összeget (illetve a néhány év múlva nagy valószínűséggel elért összeget) kell figyelembe venni a legkisebbnek választható adattípus meghatározásához.

Ha measure-ünk nem minden dimenziója tartalmaz [All] elemet, mint például az idő dimenzió, amelyen nincs az évek összegét mutató [All] elem, akkor itt évenként kell meghatározni az összeget, és azt kell megnézni, hogy az így kapott összeg belefér-e az adattípusba.

A fentiek mintája alapján meghatározható a nem sum szerint felösszegzett measure-ök legkisebb adattípusa is (pl.: Semi-addittive measure-ök.)

Ha measure-ünkre definiáltunk MeasureExpression-öket, akkor értelem szerűen nem a fact táblában szereplő összegeket kell figyelembe venni a legkisebb adattípus meghatározásakor, hanem a MeasureExpression eredményeképp előálló összegeket. Szintén, ha az MDX script-ben definiál valamilyen aggregációt, akkor előfordulhat, hogy a fenti módszerekkel meghatározott adattípus kevésnek bizonyul.

Összefoglalva: Mindig fordítson időt a measure-ök adattípusának helyes megválasztására. Ha fölülméretezi őket az csak a teljesítmény rovására megy, de ha alul, akkor az már adathibát eredményez!

Elválasztó

Már készül a következő cikk. Kérjen értesítést a megjelenéséről itt.

|

Szóljon hozzá!

Szabály: Legyen kedves, segítõkész és vállalja a nevét.
A mező tartalma nem nyilvános.
  • A web és email címek automatikusan linkekké alakulnak.
  • Engedélyezett HTML elemek: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • A sorokat és bekezdéseket automatikusan felismeri a rendszer.
ANTI SPAM
A robot regisztrációk elkerülésére.
Image CAPTCHA
Figyeljen a kis és nagybetűk használatára