Articole

Microsoft Technet Romania - SQL Server 2008 - Elemente noi in Transact-SQL

xmldeveloper — Sun, 18 May 2008 18:37:52 GMT

Microsoft Technet Romania - SQL Server 2008 - Elemente noi in Transact-SQL

Microsoft Technet Romania - SQL Server 2008 – Backup Compression

xmldeveloper — Mon, 07 Apr 2008 19:21:51 GMT

SQL Server 2008 – Backup Compression

Descoperirea partitiilor pas cu pas

ggciubuc — Mon, 16 Oct 2006 08:31:17 GMT

Descoperirea partitiilor pas cu pas

Partitiile sunt mecanismul prin care in SQL 2005 se pot distribui date ale unui tabel pe mai multe filegroup-uri pe baza unui criteriu de impartire. Beneficiile utilizarii acestuia sunt mari , lista lor o gasiti sigur prin MSDN (aici Cristi Lefter sau altcineva dintre dvs. ma puteti ajuta cu un link catre astfel de resurse).
In continuare vi se va desfasura un film al incercarilor mele facute pentru testarea acestui mecanism. Daca este prost sau mai trebuie imbunatatit, dumneavoastra o puteti spune, insa sigur puteti trece de la postura de spectator la cea de regizor, masinist, sunetist, cascador sau ce mai vreti …

Folosesc aceeasi baza de date “chioara” facuta candva intr-un articol. Citind “scenariul” oferit de Books Online aflu ca trebuie facuta o functie pentru partitie:

CREATE PARTITION FUNCTION [myRangePF1](int) AS RANGE LEFT FOR VALUES (1, 100, 1000)

Aceasta se numeste “myRangePF1” si imparte datele in 4 partitii :

Partitia 1 intregi pana la borna 1 (inclusiv 1 pentru ca apare LEFT)

Partitia 2 intregi intre 1 si 100 inclusiv

Partitia 3 intregi intre 100 si 1000 inclusiv

Partitia 4 intregi peste 1000

(daca as fi folosit RIGHT in loc de LEFT am fi avut de exemplu

Partitia 3 intregi intre 100 inclusiv si 1000)

Mai departe trebuie sa fac o asociere intre aceste zone unde se vor duce datele si filegroup-uri. Pentru asta construiesc intai 4 filegroupuri test1fg, test2fg, test3fg, test4fg si generez o schema de partitie care face asocierea:

CREATE PARTITION SCHEME [myRangePS1] AS PARTITION [myRangePF1] TO ([test1fg], [test2fg], [test3fg], [test4fg])

Acuma bucataria e gata, mai trebuie sa pun un tabel sa se foloseasca de aceste lucruri; tabelul creat mai jos face ca pe baza coloanei “clasa” sa se faca impartirea datelor:

USE

CREATE TABLE [dbo].[test](

[id] [int] IDENTITY(1,1) NOT NULL,

[nume] [varchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,

[clasa] [int] NULL

) ON [myRangePS1]([clasa])

SET ANSI_PADDING OFF

Mai departe ma joc inserand o multime de date in tabelul nostru

declare @i int

declare @nume1 varchar(20)

set @i=0

while @i<2000

begin

set @i=@i+1

set @nume1='Gigi'+cast(@i as varchar(4))

INSERT INTO .[dbo].[test]

([nume]

,[clasa])

VALUES (@nume1

,@i)

end

Pentru a vedea ce date am si unde le am apelez la functia PARTITION.myRangePF1(clasax) care da partitia unde se depun datele ce fac parte din clasa “clasax”, si, prin interogarea urmatoare

USE a ;

SELECT $PARTITION.myRangePF1(clasa) AS Partition,

COUNT(*) AS [COUNT] FROM dbo.test

GROUP BY $PARTITION.myRangePF1(clasa)

ORDER BY Partition ;

Rezulta un numar de date ca in tabelul urmator :

Partition COUNT

----------- -----------

1 1

2 99

3 900

4 1000

(4 row(s) affected)

De asemenea pentru a vedea “icrele” depuse in partitia numarul 3 se poate lansa

select * from dbo.test

where $partition.myrangepf1(clasa)=3

Cu partitiile se pot face urmatoarele operatii:

Switching
Merging
Splitting

Daca ultimele 2 sunt un pic mai transparente(merging=unire a 2 partitii, splitting=descompunere a unei partitii) haideti sa vedem ce inseamna switching:

Iata ce date avem pe partitia nr 2

select * from test

where $PARTITION.myrangepf1(clasa)=2

id nume clasa

----------- -------------------------------------------------- -----------

2 Gigi2 2

3 Gigi3 3

…

100 Gigi100 100

(99 row(s) affected)

Creez un nou tabel test2 identic cu test in filegroupul test2fg, si inserez un rand oarecare in tabel dupa care pornesc switching:

ALTER TABLE test SWITCH PARTITION 2 TO test2 ;

Msg 4905, Level 16, State 1, Line 1

ALTER TABLE SWITCH statement failed. The target table 'a.dbo.test2' must be empty.

Asta inseamna ca test2 trebuie sa fie gol pentru a face switching.

Sterg acel rand si relansez comanda de switching, apoi vad ce date sunt pe aceasta partitie:

id nume clasa

----------- -------------------------------------------------- -----------

(0 row(s) affected)

Asta inseamna ca prin switching datele de pe partitia initiala sunt pierdute.

Si ca sa nu fiu dator cu celelalte operatii:

ALTER PARTITION FUNCTION myRangePF1()

MERGE RANGE (100)

Da urmatoarele rezultate:

Partition COUNT

----------- -----------

1 1

2 999

3 1000

(3 row(s) affected)

Asta inseamna ca partitiile 2 si 3 s-au unit (99 + 900), iar

ALTER PARTITION FUNCTION myRangePF1()

SPLIT RANGE (500)

Ne da

Msg 7707, Level 16, State 1, Line 1

The associated partition function 'myRangePF1' generates more partitions than there are file groups mentioned in the scheme 'myRangePS1'.

Oops !

Dupa cateva cautari aflu ca trebuia sa mai am un filegroup disponibil asa ca il construiesc si pe test5fg , modific schema cu

ALTER PARTITION SCHEME myRangePS1

NEXT USED test5fg

astfel ca partitia sa recunoasca noul filegroup dupa care comanda de splitare functioneaza corect.

The End

Microsoft TechNet Romania - Integrarea PowerShell cu SQL Server 2008

xmldeveloper — Sun, 09 Mar 2008 15:01:19 GMT

Integrarea PowerShell cu SQL Server 2008

SQL Server 2008 - inovatii in domeniul securitate

xmldeveloper — Fri, 01 Feb 2008 12:21:35 GMT

Microsoft Romania TechNet - SQL Server 2008 - inovatii in domeniul securitate

Business Intelligence in SQL Server 2008

xmldeveloper — Sat, 19 Jan 2008 19:28:02 GMT

Articol publicat pe site-ul Microsoft Romania: Business Intelligence in SQL Server 2008

Functionalitati noi in SQL Server 2008 (living document)

xmldeveloper — Wed, 25 Jul 2007 15:30:08 GMT

Transparent data encryption
External key management
Data Auditing
Hot Add CPU
Transparent failover for Database Mirroring
Automatic recovery from page corruption
Log stream compression (Database Mirroring)
Declarative Management Framework
Server Group Management
Streamlined installation
Enterprise System Management
Performance Data Collection
System Analysis
Data compression
Resource Governor
Query Optimization Modes
Entity Data Model
Language Integrated Query (LINQ)
Visual Entity Designers
Entity Aware Adapters
SQL Server Change Tracking
Synchronized Programming Model
Visual Studio Support
SQL Server Conflict Detection
FileStream data type
Integrated Full-Text Search
Sparse columns
Large user-defined types
Date/Time Data types
LOCATION data type
SPATIAL data type

Data compression

Backup compression

Partitioned table parallelism

Star join query optimizations

Resource Management

Grouping Sets

Change Data Capture

MERGE SQL statement

Scalable Integration Services

SQL Server Integration Services (SSIS) pipeline improvements

SSIS persistent lookups

Analysis scale and performance

Block computations

Writeback

Enterprise Reporting Engine

Better scale-out configuration

Internet report deployment

Manage the reporting infrastructure

Report Builder enhancements

Built-in forms authentication

Report Server application embedding

Office integration

TABLIX

In plus:

FORCESEEK table hint

T-SQL Row Constructors

New Dynamic Management Views

Visual designer, and add nodes to a peer-to-peer replication configuration without stopping system activity

Performance Studio to troubleshoot, tune, and monitor

Table-valued parameters

Table-valued constructors

One statement variable declaration/assignment, increment operators

HierarchyID data type

Large User Defined Aggregates

New versions of ODBC driver, OLE DB provider, and ADO.NET data provider

SQLCE Version 3.5

Alte Facilitati neconfirmate oficial:

Intellisense

Debug in SSMS

Episodul nr. 4 : "Arborii si cowboy-ii"

ggciubuc — Fri, 22 Sep 2006 12:14:09 GMT

Din seria “Microsoft SQL Server 2005 in actiune”

Astazi episodul nr. 4 :

"Arborii si cowboy-ii"

O productie “Admindate & Inf, www.diadmin.ro” , 2006

Scenariul si regia Gheorghe Ciubuc

Personaje principale:

Alejandro Morientes – DBA in firma “Los capshunares” cu activitati principale in agricultura, undeva in Spania, langa Madrid, anul de gratie 2006.

Pedro Garcia – patronul firmei, 50 de ani .

Maria-Elena Adochitei – romanca,bunaciunea nr. 1 nascuta la Vaslui, aici printre capsuni.

Miguel Morales – unu din managementul firmei si actionar al ei.

Consuela Cervantes – bunaciunea nr. 2, secretara dl. Pedro Garcia.

Pedro Garcia(cu telefonul in mana)”Alejandro, vino pana la mine in birou”

Alejandro Morientes(baiguind)” Da, Sefu’, imediat”

Alejandro urca cu inima cat un purice pana la biroul sefului de la etajul 1 care este langa secretariat.

Consuela:”Alejandro, mi amor, ce-i cu tine…”

Alejandro:”Uite ma cheama seful, ce o avea cu mine, nu cumva…”

Consuela:”Stai draga linistit, probleme cu Uniunea Europeana, acu’ ca o sa-i bage si pe romani si pe bulgari…”

Alejandro(bagand capul pe usa): “Traiti’ Sefu ”

Pedro Garcia:”Ce-i ma cu tine? “(Alejandro se albi ca varul)”te-am chemat de o juma’ de ora !”

Alejandro(sufland usurat):”Sefu, a trebuit sa downloadez….”

Pedro Garcia:”Bine, bine. Uite care-i problema : vreau sa mi se prezinte o situatie in care sa vad sefii cu subalternii pe ferme, sa stiu si eu care-i sef si care grajdar. Noi avem toti oamenii bagati in calculator, nu?

Alejandro:”Da, sefu, ma gandesc…”

Pedro Garcia:”Pai munceste nu gandeste!”

Alejandro(ranjind cu subinteles):”Sigur, facem si d’astea.Sefu, ma duc pe jos sa pregatesc. Cred ca o sa folosesc CTE-uri”.

Pedro Garcia:”Cu ce vrei numai sa rezolvi!”

Dupa un timp Alejandro, prezenta situatia sefului. Iata cum a facut:

Datele sunt inregistrate in baza de date astfel

ID(cod angajat) Nume (Nume angajat) IDM(Codul sefului acestui angajat)

(Primele randuri arata astfel)

12123 Pedro Garcia Null

23411 Miguel Morales 12123

….

(Null inseamna ca Pedro Garcia nu are sef – e normal, doar e patronul!)

Mai departe, foloseste common table expression (CTE)- o structura care permite cautari recursive pe aceasi tabela

USE Ferma;

WITH Ierarhie (IDM, ID, Nume, Nivel)

-- “Ierarhie” este numele structurii

(

-- Definesc inceputul ierarhiei(de unde se pleaca, radacina)

SELECT IDM,ID,Nume,0 as Nivel

from dbo.emp

WHERE IDM IS NULL

UNION ALL

-- Definesc recursivitatea

SELECT e.IDM, e.ID, e.Nume,Nivel + 1

FROM dbo.emp AS e

INNER JOIN Ierarhie AS d

-- astfel scot angajatii care au sef(e.IDM) exact codul managerului selectat(d.ID)

ON e.IDM = d.ID

)

-- Instructiunea care executa CTE-ul(Common Table BLOCKED EXPRESSION

SELECT IDM as CodSef, ID as CodAngajat, Nume as NumeAngajat, Nivel

FROM Ierarhie

SFARSIT

Regia ………………………………………………………………..Ciubuc Gheorghe

Scenariul(dupa un document Microsoft)……………………....………Ciubuc Gheorghe

Producator………………………………………………………….. Ciubuc Gheorghe

O productie Admindate & Inf, www.diadmin.ro”

Clauza FOR XML

xmldeveloper — Thu, 19 Oct 2006 07:57:53 GMT

Clauza FOR XML

Clauza FOR XML pentru instructiunea SELECT a fost introdusa in SQL Server 2000 si permite generarea de xml dintr-un set de randuri. In SQL Server 2005 clauza este imbunatatita printre noutati fiind:

§ directiva TYPE – care permite returnarea rezultatului generat de interogarea FOR XML in formatul xml

§ directiva ELEMENTS pentru modul RAW - valoarea fiecarei coloane este mapata folosind un sub-element al elementului <row> (SQL Server 2000 folosind atribute)

§ specificarea unui nume pentru elementul <row>

§ suport pentru valorile NULL – coloanele cu valori NULL pot genera empty elements (elemente vide) cu atribututul xsi:nil prin specificarea optiunii XSINIL

§ generare schema – o data cu rezultatele interogarii se poate genera si o schema XSD pentru acestea folosind cuvantul cheie XMLSCHEMA

§ modul PATH – permite specificarea numelor coloanelor folosind sintaxa similara limbajului XPATH pentru maparea valorilor generate in atribute, elemente etc.

Exemple:

USE AdventureWorks;

--exemplu directiva TYPE

SELECT ContactID AS Id_Contact,

FirstName AS Prenume, LastName AS Nume

FROM Person.Contact

FOR XML AUTO, TYPE;

-- exemplu directiva ELEMENTS

SELECT ProductModelID AS Id_Model, Name AS Nume

FROM Production.ProductModel

FOR XML RAW, ELEMENTS;

-- specificare nume pentru

-- elementul <row>

SELECT ProductModelID AS Id_Model, Name AS Nume

FROM Production.ProductModel

FOR XML RAW ('ProductModel');

-- suport pentru valorile NULL

SELECT ProductID AS Id_Produs, Name AS Nume, Color AS Culoare

FROM Production.Product

FOR XML RAW, ELEMENTS XSINIL;

-- modul PATH

SELECT ProductModelID AS "@Id_Produs",

Name AS Nume

FROM Production.ProductModel

FOR XML PATH;

Iar si iar despre baze de date de tip “snapshot”

ggciubuc — Thu, 12 Oct 2006 11:40:49 GMT

Asa cum o si spune numele, o astfel de baza de date creeaza o imagine instantanee, statica a unei baze de date utilizator (nu si de sistem). Astfel ca incarcarea adusa de interogari intensive poate fi echilibrata prin utilizarea acesteia.

Tehnica pe care sistemul o foloseste la redarea datelor are numele “copy-on-write”. Iata cum merg lucrurile: initial sistemul construieste un schelet gol (un fisier “sparse”) care face trimitere la paginile de date originale; pe masura ce paginile bazei de date se modifica , ca urmare a unui update pe un tabel de exemplu , acestea se copiaza in fisierul sparse astfel ca la o interogare a bazei de date snapshot se pot folosi date de pe baza de date originala dar si din fisierul “sparse.”.

Iata cum arata comanda de creare a unei astfel de baze de date :

CREATE DATABASE a_Snapshot1248 ON

( NAME = N'a', FILENAME =N'D:\Microsoft Learning\2779\Teste\A_1248.ss')

AS SNAPSHOT OF a

unde “a ” este baza de date originala , “D:\” este o partitie neaparat NTFS lansata numai pe o editie “Enterprise” a SQL 2005.

Mai departe se poate pune problema invers: pot reface baza de date a folosind un snapshot?

Da, in comanda de restaurare se prevede si o astfel de optiune. Inainte de a va prezenta un astfel de exemplu mai fac un lucru, pentru a impusca 2 iepuri dintr-o data si anume adaug bazei de date inca un fisier de log .

Comanda restore database a from database_snapshot='a_Snapshot1248'

reface baza de date “a” exact ca in momentul crearii snapshot-ului, inlaturand si fisierul de log de adineaori.

Database Snapshots

xmldeveloper — Thu, 12 Oct 2006 13:20:17 GMT

Database Snapshots

Database Snapshots ofera posibilitatea de a obtine rapid o imagine consistenta si read-only a unei baze de date.

Aceasta facilitate nu inlocuieste o strategie de backup/restore fiind un mecanism pentru protectie impotriva erorilor generate de aplicatii sau utilizatori.

Se poate folosi

pentru obtinerea unei baze de raportare
ca baza de test
ca metoda complementara de recuperare a datelor

SQL 20005 foloseste un mecanism de tip copiere la scriere pentru a implementa un snapshot. Aceasta implementare a avut ca scop principal performanta deoarece la crearea unui snapshot exista doar unul sau mai multe fisiere goale iar paginile de date sunt copiate doar daca sunt modificate.

Cand o pagina este modificata pentru prima data in baza de date sursa , este copiata si in database snapshot-ul creat, iar modificarile ulterioare sunt ignorate.

La citirea din database snapshot, paginile nemodificate vor fi citite din baza de date sursa iar paginile modificate vor fi citite din database snapshot.

Pentru crearea unui snapshot cu numele snapshot_name se foloseste sintaxa:

CREATE DATABASE snapshot_name

(

NAME=logical_file_name

FILENAME='os_file_name'

) [,...n]

AS SNAPSHOT OF source_database_name[;]

Imbunatatirea performantei cuburilor OLAP in Analysis Services 2000

cubeman — Mon, 30 Oct 2006 11:23:35 GMT

Imbunatatirea performantei cuburilor OLAP in Analysis Services 2000

Cind vorbim despre performanta cuburilor OLAP, ne referim in principal la urmatoarele 2 aspecte:

1. Performanta la procesarea cuburilor
2. Performanta la interogarea cuburilor de catre utilizatori.

Pentru inceput, precizez ca exemplele din acest document au fost construite pe baza demonstrativa FoodMart livrata impreuna cu Analysis Services 2000.

1. Performanta la procesarea cuburilor

Procesarea reprezinta procesul de alimentare a cuburilor OLAP pe baza de selecturi rulate pe baza de date relationala specificata in datasource-ul bazei de date. Trebuie precizat ca procesarea unui database / cube cu optiunile Full Process / Incremental Update are ca efect generarea unui folder Shadow in care practic este generata o nou baza de date cu toate fisierele aferente, iar doar in momentul terminarii procesarii (commit transaction), aceasta baza de date temporara inlocuieste baza de date originala. De-a lungul procesarii unui cub utilizatorii ramin conectati, fiind deconectati temporar doar in momentul in care se face commit transaction.

In cadrul operatiunii de procesare sint rulati urmatorii pasi:

a. Procesarea dimensiunilor.

In momentul crearii fiecarei dimensiuni , in diagrama dimensiunii au fost adaugate una sau mai multe tabele, pe baza carora au fost create level-urile dimensiunii. Dimensiunile sint construite pe baza tabelelor de referentiale.

Spre exemplu, pentru popularea dimensiunii Store este rulat urmatorul select asupra bazei de date relationale.

SELECT DISTINCT "store"."store_country", "store"."store_state", "store"."store_city", "store"."store_id", "store"."store_name" FROM "store"

Operatiuni similare sint rulate asupra tuturor dimensiunilor bazei de date multidimensionale, scopul acestei operatiuni fiind acela de a repopula dimensiunile pe baza celor mai recente informatii provenind din baza de date relationala.

b. Procesarea Partitiilor

Datele fiecarui cub sint stocate in una sau mai multe partitii, care contin de fapt inregistrarile, stocate in format multidimensional, provenite din tabela de fapte a cubului. Dintre toti pasii executati la procesare, acest pas este, alaturi de procesarea modelelor de Data Mining ) , printre cele mai consumatoare din punctul de vedere al consumului de timp, intrucit tabelele de fapte pot contine milioane de inregistrari, numarindu-se printre tabelele cele mai mari existente la nivel de datawarehouse.

Urmatorul select a fost utilizat pentru popularea partitiei Budget_1997 a cubului Budget:

SELECT "expense_fact"."account_id", "expense_fact"."store_id", "expense_fact"."category_id", "time_by_day"."quarter", "time_by_day"."month_of_year", "expense_fact"."amount" FROM "expense_fact", "time_by_day" WHERE ("time_by_day"."the_year"=?) AND ("expense_fact"."time_id"="time_by_day"."time_id")

c. Procesarea Modelelor de Data Mining

Pe baza inregistrarilor stocate in partitii, modelele de data mining sunt“antrenate” astfel incit sa corespunda modificarilor aparute la nivel de datawarehouse.

Supravegherea permanenta a performantei la procesare a cuburilor este una din atributiile deosebit de importante ale unui administrator OLAP, intrucit exista constringeri de timp foarte clar definite. Spre exemplu, daca importul la nivel de datawarehouse incepe la ora 01:00 AM si se termina la ora 04:00 AM, in intervalul 04:00 AM - 07:30 AM toate cuburile trebuiesc procesate astfel incit, la ora 08:00 AM , atunci cind utilizatorii ajung la serviciu, toate cuburile sa fie updatate pe baza informatiilor din ziua precedenta.

Performanta la procesarea cuburilor depinde de urmatorii factori:

I.      Setari existente la nivel de datawarehouse
a.       Una din optiunile extrem de importante care determina performanta la procesare este constituita de alegerea unui view sau a unei tabele ca si tabela de fapte a cubului.

De regula se prefera alegerea unui view atunci cind informatiile necesare tabelei de fapte a unui cub provin din mai multe tabele de fapte, fiecare continind informatii diferite precum:
i.      Vinzari de produse pe magazin
ii.      Stoc de produse pe magazin
iii.      Costuri de productie pentru fiecare produs
In conditiile in care acest view este constituit din mai multe selecturi simple rulate pe fiecare dintre tabelele componente, utilizand clauza union, atunci selectul prezinta avantajul al economisirii spatiului pe disk, necesar stocarii tuturor acestor informatii.

Marele dezavantaj al folosirii view-ului pe post de tabela de fapte apare in momentul in care acesta este format din selecturi complexe, iar cubul al care foloseste aceasta tabela de fapte contine numeroase partitii. In aceste conditii, pentru procesarea fiecareia dintre partitii este necesara reconstruirea view-ului, operatiune care poate fi extrem de costisitoare ca si timp.

b.      In conditiile cuburilor partitionate si a utilizarii view-urilor ca si tabele de fapte ale cuburilor, se recomanda utilizarea de constrangeri pentru fiecare dintre tabelele implicate in view. Spre exemplu, daca partitiile dintr-un cub sint create utilizind criteriile Business Unit & Time Civil, este recomandabil ca pentru fiecare pereche Business Unit & Time Civil sa existe cite o tabela. In conditiile in care pentru fiecare tabela au fost definite constringeri pe aceste 2 cimpuri (ex. BUSINESS_UNIT & ACCOUNTING_DATE), la procesarea fiecareia dintre partitii, desi este folosit un view ca tabela de fapte, selectul propriu-zis va fi rulat doar pe tabela care indeplineste conditiile precizate mai sus, imbunatatind dramatic timpul de procesare, mai ales in cazul view-urilor care contin milioane de inregistrari.

c.       Definirea de indecsi clustered la nivel de tabela de fapte, pentru cimpurile pentru care sint definite partitiile, intrucit aceste filtre vor fi folosite simultan la procesarea partitiilor.

d.      Utilizarea de indecsi simpli pentru toate cimpurile de tip foreign key din tabela de fapte, intrucit aceste cimpuri sint utilizate pentru realizarea legaturii cu tabelele de referentiale.
II.      Setari existente la nivel de Analysis Services
a.      Modul de procesare al cuburilor

Problema unui administrator OLAP este aceea de a decide, in functie de modalitatea de   desfasurare a activitatii companiei si de modficarile tehnice asupra cuburilor, pentru una din cele 3 modalitati de procesare:
i.            Incremental update – sint aduse in cub doar noile inregistrari aparute la nivel de datawarehouse, fara reprocesarea agregarilor. Aceasta modalitate de procesare este cea mai rapida insa nu poate fi folosita decit in conditiile in care modificarile la nivel de datawarehouse constau doar in adaugarea de noi inregistrari, fara modificarea celor existente.
ii.            Refresh data – repopuleaza tot cubul iar agregarile sint recalculate. In toata aceasta perioada utilizatorii pot interoga insa, ca si viteza de procesare, aceasta modalitate de procesare este mai lenta decit incremental update si nu poate fi folosita in cazul modificarilor de structura la nivelul cubului.
iii.            Full Process – necesara in conditiile modificari structurii cubului sau a dimensiunilor. Utilizatorii pot accesa noile date doar dupa reconectarea la cub.
b.      Modul de procesare al dimensiunilor
i.       Incremental Update – deosebit de utila in cazul in care in dimensiuni apar doar noi elemente, fara a fi efectuate modificari asupra elementelor existente. Spre exemplu, daca dimensiunea Products contine 10.000 de membrii si in urma importului din datawarehouse au aparut 100 de noi produse, atunci dimensiunii existente I se vor adauga doar aceste noi produse, fara a se efectua modificari asupra datelor existente. Procesarea unei dimensiuni cu Incremental Update nu atrage in mod obligatoriu si reprocesarea cubului.
-      Acest tip de procesare nu poate fi totusi aplicat, spre exemplu ,in cazul in care in dimensiunea Products, pe linga noile produse adaugate s-au modificat descrieri ale produselor existente, in acest caz fiind obtinuta o eroare la procesarea dimensiunii.
-      In cadrul procesarii Incrementale, agregarile existente la nivel de cub nu sint recalculate. Agregarile reprezinta totaluri precalculate, care contin valoarea intersectiei mai multor membrii ai unei dimensiuni. In momentul in care un utilizator lanseaza o interogare asupra cubului, mai intai se incearca indentificarea unei agregari existente pentru acea solicitare, iar daca acea agregare nu exista, atunci sistemul va trebui sa calculeze in momentul executiei valoarea corespunzatoare intersectiei de dimensiuni specificata de utilizator.
ii.   Rebuild dimension structure - aceasta optiune permite repopularea completa a unei dimensiuni, oferind si avantajul recalcularii agregarilor. Se recomanda ca aceasta optiune sa fie utilizata in cazul unor modificari dese la nivel de datawarehouse, constind atit in adaugarea de noi date cit si in modificarea celor existente, sau la modificarea structurii dimensiunii.

Aceasta metoda de procesare este cea mai sigura, insa prezinta dezavantajul major al faptului ca dupa o astfel de procesare, toate cuburile care contin acea dimensiune sint invalidate, trebuind reprocesate cu Full Process. In toate aceasta perioada utilizatorii NU se mai pot conecta la cuburile afectate.

2. Performanta la interogarea cuburilor de catre utilizatori.

a. Definirea de partitii adecvate criteriilor de selectie ale utilizatorilor

Rolul partitiilor in performanta la interogare a cuburilor devine evident daca ne gindim la modul in care utilizatorii acceseaza datele din cuburile OLAP. Spre exemplu, pentru o companie multinationala, cu mai multe business locations distribuite in intreaga lume, cei care acceseaza datele sint controlori de gestiune. Accesele acestora sint date de regula doar pentru o anumita locatie geografica (ex. Romania), doar pentru utilizatorii din HeadQuarters fiind definite accese pe toate locatiile geografice (sau locatii de business – Business Units).

In cazul unul cub care are doar o singura partitie, orice select dat de un utilizator va avea ca rezultat parcurgerea de milioane de inregistrari, intrucit ,chiar daca cunosc de la inceput pentru ce business unit si ce perioada fiscala caut datele, sistemul nu are nici o modalitate de a individualiza inregistrarile respective fara a efectua o cautare prin toate inregistrarile cuprinse in partitia respectiva.

In conditiile in care avem partitii definite la nivel de an fiscal si de business unit, sistemul va identifica cu exactitate, in functie de selectul lansat de utilizator si de drepturile acestuia, care este partitia care trebuie interogata, restrangand astfel nr. de inregistrari care trebuie parcurse pentru a raspunde solicitarii utilizatorului.

b. Aggregation design-ul definit la nivel de partitii

Agregarile reprezinta unul din factorii esentiali care determina performanta la interogare a unui cub, intrucit contin stocate totaluri precalculate pentru intersectiile de dimensiuni. Totusi, calcularea agregarilor are ca efect atit cresterea timpului de procesare al cubului cit si a nevoilor de spatiu de stocare. Rolul administratorului OLAP este acela de a gasi un echilibru intre nevoile de sporire a performantei la interogare a cubului si necesitatea ca timpul de procesare al unui cub sa se incadreze in constringerile de timp definite.

In conditii normale de exploatare a cuburilor, pe masura ce volumul de date existent la nivel de datawarehouse creste, creste si timpul necesar pentru atingerea aceluiasi nr. de agregari pentru fiecare partitie in parte. Pentru prevenirea degradarii performantei la procesare, se recomanda dezvoltarea unei strategii axata pe urmatorul scenariu standard:

Utilizatorii acceseaza cel mai frecvent date pentru anul fiscal curent & anul fiscal precedent, de regula avind drepturi de access doar pe anumite companii. In aceste conditii, este nevoie de un timp de raspuns foarte bun pentru cele doua perioade fiscale, intrucit acestea sint cel mai frecvent accesate, ceea ce inseamna un nr. Sporit de agregari. Pentru celelalte perioade fiscale, care sint mai rar accesate, se poate recurge la reducerea nr. de agregari.

Toata aceasta strategie are ca scop mentinerea sub control a timpului de procesare, in conditiile inbunatatirii timpului de raspuns pentru cele mai frecvente interogari ale utilizatorilor. Trebuie precizat faptul ca o astfel de strategie nu poate fi aplicata decit cuburilor partitionate, cel putin la nivel de perioada fiscala, intrucit acesta este de regula cel mai frecvent criteriu de selectie al utilizatorilor.

c. Servere OLAP Regionale

In conditiile existentei unei companii multinationale, exista mai multe locatii de unde utilizatorii se conecteaza la cuburile OLAP. Spre exemplu, daca server-ul de DataWarehouse si serverul OLAP se afla in SUA, iar numerosi utilizatori utilizatori din Europa se conecteaza la aceste cuburi OLAP, este evident ca utilizatorii din America de Nord vor fi favorizati datorita unei viteze de comunicare superioare fata de cea de care beneficiaza utilizatorii din Europa.

In astfel de situatii este recomandata utilizarea de servere OLAP regionale, care sa aduca sursa de date mai aproape de utilizatori.Astfel, un server OLAP regional in Europa rezolva, pentru utilizatorii de pe continent, problema constituita de o slaba conexiune de retea intre Europa si SUA. Cuburile vor fi procesate in fiecare noapte pe serverul OLAP de productie din SUA si replicate dupa aceea pe serverul regional din Europa, urmind ca utilizatorii din fiecare locatie geografica sa se conecteze la serverul cel mai apropiat, imbunatatind astfel radical timpul de raspuns la interogare.

In speranta ca aceste informatii va vor fi de folos , inchei aici prezentarea legata de Imbunatatirea performantei cuburilor OLAP in Analysis Services 2000.

Spor la treaba.

Guse Nicolae

Business Intelligence Engineer

Ubisoft

Instalarea si Configurarea Analysis Services 2000

cubeman — Mon, 30 Oct 2006 11:22:27 GMT

Instalarea si Configurarea Analysis Services 2000

Analysis Services reprezinta solutia OLAP cu care Microsoft a patruns pe piata Business Intelligence. Aventura companiei in domeniu incepe in anul 1996 odata cu achizitionarea tehnologiei Panorama Online Analytical Processing, dezvoltata de compania israeliana Panorama Software.

Prima implementare a unei solutii OLAP intr-un produs Microsoft incepe cu OLAP services, integrat pentru prima data in Sql Server 7.0. Incepind cu Sql Server 2000 produsul a fost redenumit in Analysis Services iar functionalitatea sa mult extinsa. Compania a acordat deosebita atentie acestui produs , facind parte dintr-o strategie de a adduce Business Intelligence mai aproape de utilizatorii finali, acestia platind doar pretul unei licente sql server. Tocmai aceasta integrare cu sql server a avut ca rezultat ascensiunea rapida a Microsoft in domeniul Business Intelligence, la capitolul Market Share devenind lider incepind cu anul 2002 si depasind concurenti de marca precum Hyperion, Cognos sau Business Objects.

Pentru detalii suplimentare puteti consulta:

http://www.olapreport.com/market.htm

I. Versiuni Analysis Services

In prezent , exista mai multe versiuni de Analysis Services, strins legate de distributiile Sql Server aflate pe piata:

a. Analysis Services 32 bit
b. Analysis Services 64 bit

Posibilitatile de a instala una din cele 2 versiuni sint strins legate de versiunea de server folosita. Spre exemplu , Analysis Services 64 bit nu poate fi instalat pe sisteme de operare precum Windows 2000 Server , Windows 2000 Advanced Server si Windows 2000 Datacenter, intrucit acestea sint sisteme de operare pe 32 de biti.

Limitarile Analysis Services 32 bit sint legate in primul rind de cantitatea de memorie fizica care poate fi adresata. Sub Windows 2000 Server AS2000 nu poate adresa mai mult de 2 GB de memorie fizica. Pentru depasirea acestei limitari, este necesara activarea switch-ului /3G in boot.ini, care permite AS2000 sa foloseasca pina la 3 GB de memorie RAM. Totusi, pentru activarea acestei optiuni este necesar ca sistemul de operare sa fie minim Windows 2000 Advanced. Aceasta limitare a AS2000 32 bit este datorata faptului ca acesta nu suporta Address Windowing Extensions (AWE), in ciuda faptului ca Sql Server 32 bit cu care produsul AS este integrat suporta AWE.

Este evident ca aceasta limitare impiedica folosirea AS2000 in varianta 32 bit pentru implementarea de solutii complexe, in care dimensiunea cuburilor OLAP pot fi de ordinul GB. Pentru aceste cazuri este necesara utilizarea Analysis Services 64 bit impreuna cu urmatoarele sisteme de operare:

c. Windows Server 2003 Enterprise Edition 64 bit version -> permite adresarea pina a 64 GB de memorie fizica.
d. Windows Server 2003 Datacenter Edition 64 bit version -> permite adresarea pina a 512 GB de memorie fizica.

Pentru detalii suplimentare puteti consulta:

http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/anservog.mspx

II.      Tips & Tricks la instalarea AS 2000

a.   Procesarea si interogarea cuburilor OLAP sint procese mari consumatoare de resurse. Din aceste considerente, precum si datorita limitarilor AS2000 in varianta 32 de bit in exploatarea memoriei disponobile, este recomandabila separarea serverului de datawarehouse de serverul OLAP. Aceasta separare va avea ca effect imbunatatirea timpului de procesare precum si reducerea timpului de rapsuns la interogarea cuburilor.
b.   Din considerente de siguranta a datelor, este recomandata instalarea Data folder-ului din Analysis Services pe o partitie separate de aceea pe care este stocat sistemul de operare.
c.   Configurarea corecta a memoriei in AS2000 este un factor extrem de important in determinarea performantei serverului OLAP. Urmatorii parametrii sint folositi pentru configurarea memoriei in AS:
i.      Memory conservation threshold -> reprezinta cantitatea maxima de memorie alocata AS
ii.      Minimum allocated memory -> reprezinta cantitatea minima de memorie alocata AS
iii.      Process buffer -> cantitatea de memorie utilizata la procesarea cuburilor / dimensiunilor

Un element important in gestionarea memoriei il constituie procesul cache cleaner, care incepe sa actioneze in momentul in care memoria ocupata de AS ajunge la jumatatea distantei intre minimum alocated memory si memory conservation threshold (middle point), eliminind din memoriile datele tinute in cache cele mai infrecvent folosite.

Middle Point = (Memory Conservation Threshold – Minimum allocated memory) / 2 + Minimum allocated memory
In momentul in care cantitatea de memorie folosita de AS depaseste cu 6.25% valoarea Memory conservation threshold, cache cleaner-ul actioneaza agresiv golind toate inregistrarile din cache ,pentru a preveni cazul in care serverul olap ar ramane fara memorie disponibila. O setare corecta a memoriei tb. Sa asigure un echilibru intre necesarul de memorie pentru functionarea normala as serverului OLAP si cantitatea de cache necesara pentru un bun timp de raspuns la interogarile utilizatorilor.
Pentru functionarea corecta a serverului OLAP este absolut necesar ca AS sa poata aloca, in orice moment, cel putin cantitatea cantitatea minima de memorie, in caz contrar aparind memory leaks. Acesta este si unul din motivele pentru care se recomanda separarea arhitecturii de datawarehouse de cea de Analysis Services pe servere diferite.

d. Pentru stocarea tuturor obiectelor disponibile in instanta curenta analysis services:

i.      Server
1.      Database
a.       Cubes
i.      Dimensions
1.      Levels
ii.      Measures
iii.      Roles
Este utilizat Analysis Services repository. By default, acest repository este stocata intr-o baza de date MS Access , in fisierul msmdrep.mdb. Aceasta baza de date contine urmatoarele tabele:
I.      Server -> contine informatii referitoare la versiunea de Analysis Services curent instalata
II.      OlapObjects -> contine layer-ul de metadata pentru toate obiectele mentionate mai sus, descrierea acestor obiecte fiind disponibila intr-un string XML.
Orice solicitare de consultare a unui obiect stocat pe serverul MS OLAP avea ca efect interogarea bazei de date repository. Aceasta baza de date este consultata insa in mod diferit de catre :
I.      Administratori OLAP
II.      Utilizatori
Administratorii OLAP se conecteaza prin Interfata Analysis Manager, accesind baza de date in mod read / write.
Utilizatorii se conecteaza la serverul OLAP utilizind, de regula, urmatoarele tipuri de aplicatii :
I.      Pivot table service din Microsoft Excel
II.      Aplicatii de browsing a cuburilor OLAP bazate pe Microsoft Office Web Components
III.      Aplicatii specializate de browsing OLAP dezvoltate pe tehnologii proprietare de cate Business Objects, Cognos, etc.
Din orice aplicatie s-ar conecta acestia, accesul lor la datele din repository este strict de tip read.
Una dintre problemele tipice care apar in exploatarea Serverului Analysis Services o constituie posibilitatea de corupere a bazei de date repository, care devine susceptibila la corupere in conditiile in care un Administrator OLAP se conecteaza prin interfata Analysis Manager de pe statia locala catre serverul OLAP, iar in acest timp survin probleme de retea. Din aceste motive este recomandata programarea de operatiuni de back-up zilnice pentru baza de date access msmdrep.mdb.
e.       In Analysis Services 2000 exista posibilitatea migrarii repository-ului pe o baza de date sql server. Aceasta operatiune va avea ca efect modificarea string-ului de conectare la server, respectiv inlocuirea provider-ului Microsoft.Jet.OLEDB.4.0 cu providerul SQLOLEDB.1si pointarea catre noua baza de date. In acest fel, noua baza de date poate fi inclusa in maintenace plan-urile definite la nivel de server de baze de date.
Din pacate, migrarea repository-ului din baza de date access catre sql server nu rezolva toate problemele legate de repository. Ca urmare a unui bug intern Analysis Services, la un anumit numar de operatiuni de arhivare / restaurare de cuburi olap pe un server al carui repository este migrat pe Sql Server, tabela Server din repository este golita si este obtinuta eroarea "Either BOF or EOF is True, or the current record has been deleted.

http://support.microsoft.com/default.aspx?scid=kb;en-us;823871
f.        Instalarea celei mai recente versiuni de service pack pentru Analysis Services. Cea mai recenta versiune este Service Pack 4, care rezolva o parte din problemele care au fost raportate de-a lungul timpului pentru Analysis Services 2000.
Pentru detalii suplimentare puteti consulta:

http://support.microsoft.com/?kbid=888800

In speranta ca aceste informatii va vor fi de folos , inchei aici prezentarea legata de Instalarea si Configurarea Analysis Services 2000.

Spor la treaba.

Guse Nicolae

Business Intelligence Engineer

Ubisoft

Pregatirea unui document XML pentru obiectul XmlDataSource

ggciubuc — Thu, 19 Oct 2006 10:17:44 GMT

Pregatirea unui document XML pentru obiectul XmlDataSource din VisualStudio 2005

A trebuit candva sa pregatesc un document XML pentru a fi inteles de un obiect “XmlDataSource” . Finalitatea insemna ca datele ce erau prezentate intr-un GridView sa arate ca si cum ar fi provenit de la un tabel normal (cu cap de tabel etc). Iata pasii urmati :

Intr-o fereastra de query a Management Studio lansez urmatoarea comanda, rezultatul salvandu-se in fisierul Angajat.xml

select * from(tblAngajati)

for xml auto, root ('Angajati')

Datele care apar in documentul xml sunt de felul urmator:

'<tblAngajati IDAngajat="1" " Nume="Ionescu" DataAngajare="2006-01-05T00:00:00" />

'<tblAngajati IDAngajat="2" Nume="Popescu" DataAngajare ="2006-05-15T00:00:00" />

…

</Angajati>

Dupa care n-ai decat sa setezi obiectul XmldataSource in cadrul proiectului Visual Studio:

XmlDataSource2.XPath = String.Format( _

"/Angajati/[@IDDepartament=" & GridView1.SelectedValue & "]")

GridView2.DataBind()

Tipul de date XML

xmldeveloper — Thu, 19 Oct 2006 07:54:03 GMT

Tipul de Date XML

Un tip nou de date suportat de SQL Server 2005 este tipul de date xml. Tipul de date xml permite stocarea de documente in format xml sau fragmente de documente xml avand o dimensiune de pana la 2GB. Se pot declara variabile de tip xml, se pot defini tabele cu coloane de acest tip sau se pot folosi parametrii de tip xml. Optional se poate asocia o schema pentru a valida o instanta a tipului xml, schema putand fi stocata in baza de date.

Pentru stocarea tipului de date xml se foloseste modelul InfoSet (in care ordinea atributelor, spatiile nesemnificative, prefixele spatiilor de nume si declaratia XML nu este pastrata). Astfel in urmatorul exemplu variabilele x si y sunt echivalente din punct de vedere al modelului InfoSet insa distincte lexical.

Exemplu:

declare @x xml

declare @y xml

set @x = '<document nume="document xml"></document>'

set @y = '<document nume="document xml"/>'

select @x,@y

Doua instante xml nu pot fi comparate direct (insa poate fi convertit la un alt tip de date ca de exemplu varchar pentru a putea fi comparate). Din acest motiv nu putem defini o cheie primara sau unica pe o coloana de tip xml, nu putem defini o constrangere clasica sau folosi un index clasic pentru acest tip de date.

Pentru a interoga eficient tipul de date xml se foloseste limbajul integrat XQUERY si se pot defini indecsi XML (diferiti de cei clasici – permitand o interogare eficienta in cadrul unei instante si nu a unui set).

Pentru modificarea datelor se foloseste instructiunea modify - o extensie a limbajului XQUERY.

Observatii:

desi se pot stoca fragmente de documente xml acestea trebuie sa fie „bine formate”
se pot defini constrangeri pe o coloana tip xml folosind functii
se poate defini un index full-text pe o coloana tip xml
se pot asocia o valoare implicita pentru o coloana de tip xml

Suport pentru XML Schema (XSD)

xmldeveloper — Thu, 19 Oct 2006 07:58:25 GMT

Suport pentru XML Schema (XSD)

Pentru a valida o instanta a tipului de date xml (o variabila sau o coloana de tip xml) pot fi folosite scheme XML. Schemele XML sunt inregistrate ca obiecte ale bazei de date prin intermediul unor colectii de scheme (fiecare definind un spatiu de nume) create cu instructiunea CREATE XML SCHEMA COLLECTION.

Pentru modificarea sau stergerea unei colectii se folosesc instructiunile ALTER XML SCHEMA COLLECTION si respectiv DROP XML SCHEMA COLLECTION. Cuvinte cheie CONTENT sau DOCUMENT limiteaza valoarea stocata intr-o instanta la fragmente valide sau la o instanta a unui document (valoarea implicita este CONTENT).

Exemplu:

-- creare colectie

CREATE XML SCHEMA COLLECTION ExempluColectie AS

'<schema xmlns="http://www.w3.org/2001/XMLSchema">

<element name="root" type="string"/>

</schema>'

-- exemplu tabel

CREATE TABLE ExempluTabel (ID int,Coloana1 XML (ExempluColectie))

-- declarare variabila tip XML

DECLARE @v XML (DOCUMENT ExempluColectie)

-- atribuire valoare

SET @v = '<root></root>'

-- urmatoarea atribuire va esua

SET @v = '<radacina></radacina>'

XQUERY

xmldeveloper — Thu, 19 Oct 2006 07:56:01 GMT

XQUERY

XPATH este un limbaj de interogare a documentelor XML, o interogare returnand un set de date continand noduri sau valori scalare. Datorita limitarilor XPATH in cazul procesarii unor cantitati mari de date sau in cazul surselor de date multiple a fost dezvoltat limbajul XQUERY care extinde XPATH 2.0 si preia si functionalitati din XSLT (XSL Transformations – limbaj folosit pentru transformari ale documentelor XML). XQUERY permite interogari care includ documente multiple si este integrat in database engine.

O interogare XQUERY consta in doua sectiuni principale:

§ sectiunea prolog – optionala, folosita pentru declaratii (declararea spatiilor de nume, declararea schemelor)

§ sectiunea body (corpul interogarii) – interogarea propriu-zisa in care expresii XQUERY sunt folosite pentru a specifica datele ce vor fi returnate

O expresie XQUERY utilizeaza o cale XQUERY (bazata pe limbajul XPATH) pentru localizarea unui nod intr-un document xml. O cale XQUERY poate fi absoluta (locatia unui nod este decrisa fata de elementul root) sau relativa (fata de un nod identificat).

Exemple:

§ /magazin/carte - toate elementele carte continute de elementul magazin

§ /magazin/carte[1] – primul element carte continut de elementul magazin

Exemplele se bazeaza pe un document xml salvat cu numele Books.xml in directorul radacina a drive-ului C: (pentru a fi mai usor de referit).

Books.xml

<?xml version="1.0" ?>

<titlu>Functionalitati Noi In SQL Server 2005</titlu>

<autor>Narcis Ditiu</autor>

<autor>Cristian Lefter</autor>

<autor>Adrian Stoian</autor>

</autori>

</carte>

<titlu>Beginning ASP.NET 2.0 E-Commerce in C# 2005</titlu>

<autor>Cristian Darie</autor>

</autori>

</carte>

</magazin>

Specificatiile limbajului XQUERY includ instructiunile for, let, order by, where si return (cunoscute sub numele de Instructiuni FLOWR – pronuntat flower). Instructiunile FLOWR sunt similare cu SELECT-FROM-WHERE in T-SQL. Pentru exemplificare urmatorul exemplu incarca in variabila doc documentul Books.xml si returneaza toate titlurile cartilor publicate in anul 2005 ordonate dupa titlul acestora.

Exemplu:

let $doc := doc('file:///c:/Books.xml')

for $a in $doc//magazin/carte

where $a/an = '2005'

order by $a/titlu

return $a/titlu

Rezultat:

<titlu>Beginning ASP.NET 2.0 E-Commerce in C# 2005</titlu>

<titlu>Functionalitati Noi In SQL Server 2005</titlu>

SQL Server 2005 suporta un subset al limbajului XQUERY pentru a permite interogari ale datelor de tip xml. Tipul de date xml expune urmatoarele metode:

§ query() – pentru a interoga o instanta a tipului de date xml

§ value() – pentru a returna o valoare scalara avand un tip de date SQL (int, varchar etc)

§ exists() – determina existenta rezultatelor pentru o expresie XQUERY

§ modify() – folosita pentru modificari

§ nodes() – folosita pentru a genera un set de randuri dintr-un document xml

Exemple:

-- declarare si setare variabila tip xml

DECLARE @myDoc XML

SELECT @myDoc = BulkColumn

FROM OPENROWSET( Bulk 'C:\Books.xml', SINGLE_BLOB ) AS x

-- interogare folosind metoda query

SELECT @myDoc.query('for $a in /magazin/carte

where $a/an = "2005"

order by $a/@categorie

return $a/titlu')

-- returneaza valoarea atributului categorie

-- pentru prima carte

-- respectiv valoarea "SQL"

DECLARE @Categorie VARCHAR(64)

SET @Categorie = @myDoc.value('(/magazin/carte/@categorie)[1]', 'varchar(64)' )

SELECT @Categorie

XML Data Manipulation Language

xmldeveloper — Thu, 19 Oct 2006 07:56:49 GMT

XML Data Manipulation Language

Limbajul XQUERY nu permite modificarea documentelor xml, pentru modificari folosindu-se o extensie a XQUERY – XML DML (XML Data Manipulation Language).

Concret XML DML extinde XQUERY cu urmatoarele instructiuni:

§ insert – pentru adaugare

§ delete – pentru stergere

§ replace value of – pentru modificare

Instructiunile se pot folosi prin intermediul metodei modify.

Exemplu:

-- declarare si setare variabila tip xml

DECLARE @myDoc XML

SELECT @myDoc = BulkColumn

FROM OPENROWSET( Bulk 'C:\Books.xml', SINGLE_BLOB ) AS x

-- insereaza un element autor pentru al doilea

-- element carte

SET @myDoc.modify('

insert <autor>Karli Watson</autor>

into (/magazin/carte/autori)[2]')

SELECT @myDoc

Lobby pentru varchar

ggciubuc — Sat, 14 Oct 2006 07:21:33 GMT

Lobby pentru varchar

Datele de tip varchar pot fi de 2 tipuri:

cele pentru care se precizeaza o limita de pana la 8000 caractere; acestea se vad cand pui varchar(n), cu n pana la 8000

cele care care sunt "fara limita" intelegandu-se aici siruri de pana la 2Gb (2,147,483,647 bytes); se marcheaza cu varchar(max).

Mai jos vedeti niste linii de cod care verifica capacitatile varchar(max).
////////
declare @i as int
set @i=0
DECLARE @myVariable AS varchar(max)
SET @myVariable = '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890'
--datalength of @myVariable is now 100
while @i <=10
   begin
       set @i=@i+1
       set @myvariable=@myvariable+@myvariable
       print 'Data length after concatenating data : '
       print datalength(@myvariable)
   end
////////

Iata ce rezultate da codul de mai sus cand @i este pana la 10:

Data length after concatenating data :
200
Data length after concatenating data :
400
Data length after concatenating data :
800
Data length after concatenating data :
1600
Data length after concatenating data :
3200
Data length after concatenating data :
6400
Data length after concatenating data :
12800
Data length after concatenating data :
25600
Data length after concatenating data :
51200
Data length after concatenating data :
102400

Dupa a 10-a iteratie @myvariable are dimensiunea 102400.
Daca relansam acest cod cu @i cel mult 100, computerul sta in jur de 10 minute si da urmatorul rezultat
...
Data length after concatenating data :
419430400
Data length after concatenating data :
838860800
Data length after concatenating data :
1677721600
Msg 7119, Level 16, State 1, Line 11
Attempting to grow LOB beyond maximum allowed size of 2,147,483,647 bytes.
Data length after concatenating data :
Msg 7102, Level 20, State 99, Line 13
Internal Error: Text manager cannot continue with current statement. Run DBCC CHECKTABLE.

Sistemul nu a mai putut face concatenarea pentru ca ar fi depasit 2,147,483,647 bytes.

Concluzia este ca atunci cand manevrati siruri de caractere puteti folosi varchar, care sunt mai manevrabile decat cele de tip "text", avand grija sa nu depasiti "cota" de spatiu distribuita.

Tipurile Varchar (MAX) si Varbinary (MAX)

xmldeveloper — Sat, 14 Oct 2006 08:20:39 GMT

Tipurile Varchar (MAX) si Varbinary (MAX)

SQL Server 2005 introduce argumentul MAX pentru tipurile de date varchar, nvarchar si varbinary. Folosind argumentul MAX se pot stoca 2^31-1 octeti de date fata de doar 8000 in SQL Server 2000.

Avantaje:

posibilitatea stocarii datelor de dimensiuni mari fara a folosi tipurile de date text, ntext sau image
posibilitatea declararii variabilelor de tip varchar(MAX), nvarchar(MAX) sau varbinary(MAX)
posibilitatea folosirii acestor tipuri in cursoare
folosirea in interiorul unui trigger (coloanele de tip varchar(MAX), nvarchar(MAX) sau varbinary(MAX) ale unui tabel pot fi regasite in tabelele inserted si deleted)
se pot face modificari partiale ale datelor de dimensiuni mari folosind clauza .WRITE a instructiunii UPDATE
pot fi folosite functiile pentru siruri de caractere COL_LENGTH, CHARINDEX, PATINDEX, LEN, DATALENGTH, SUBSTRING

Exemple:

-- Exemplul 1

DECLARE @v1 VARCHAR(MAX)

DECLARE @v2 VARCHAR(MAX)

SET @v1 = '0123456789'

SET @v2 = replicate(@v1,10000)

SELECT datalength(@v2)

-- rezultatul va fi 100000

-- Exemplul 2

USE AdventureWorks;

-- inlocuieste 10 caractere

-- "components" devine "features"

UPDATE Production.Document

SET DocumentSummary .WRITE (N'features',28,10)

WHERE DocumentID = 3 ;

Windows Management Instrumentation

xmldeveloper — Fri, 22 Sep 2006 08:20:43 GMT

Windows Management Instrumentation

Suportul WMI in SQL Server 2005 a fost extins si este folosit prin intermediul a doi provideri WMI:

1. WMI provider pentru Configuration Management – este folosit pentru configurarea serviciilor SQL si setarilor pentru retea. Surface Area Configuration si Configuration Manager sunt doua utilitare pentru configurare care folosesc WMI. Pentru utilizare sunt disponibile urmatoarele metode:

Un limbaj de script ca VBScript, Jscript si Perl din care pot folosi Windows Query Language (WQL). WQL este un subset simplificat al SQL cu niste extensii specifice WMI.
Prin intermediul SMO folosind obiectul ManagedComputer.
Folosind utilitarul SQL Server Configuration Manager sau consola MMC cu SQL Server WMI provider snap-in.

2. WMI provider pentru Server Events – folosit pentru a monitoriza evenimentele unei instante SQL Server.

Urmatorul exemplu va utiliza o interogare WQL folosind WMI Provider pentru a enumera serviciile SQL Server.

Pentru a rula exemplul trebuie sa executati pasii urmatori:

Intr-un editor text gen Notepad deschideti un nou document si copiati codul specificat in exemplul de mai jos.
Salvati documentul cu un nume de exemplu WQLQuery.vbs.
Din linia de comanda rulati cscript WQLQuery.vbs.

Exemplu:

set wmi = GetObject("WINMGMTS:\\.\root\Microsoft\SqlServer\ComputerManagement")

for each prop in wmi.ExecQuery("SELECT * FROM SqlService")

WScript.Echo "ServiceName: " & prop.ServiceName

WScript.Echo "Description: " & prop.Description

WScript.Echo "DisplayName: " & prop.DisplayName

WScript.Echo "HostName: " & prop.HostName

WScript.Echo "ProcessId: " & prop.ProcessId

WScript.Echo "SQLServiceType: " & prop.SQLServiceType

WScript.Echo "StartMode: " & prop.StartMode

WScript.Echo "StartName: " & prop.StartName

WScript.Echo "State: " & prop.State

WScript.Echo "---------------------------------------------------------------"

next

-- Output pe calculatorul meu

ServiceName: MSFTESQL
Description: Quickly creates full-text indexes on content and properties of structured and semi-structured data to allow fast linguistic searches on this data.
DisplayName: SQL Server FullText Search (MSSQLSERVER)
ErrorControl: 1
ExitCode: 0
HostName: MICROTRAINING
ProcessId: 3088
SQLServiceType: 3
StartMode: 3
StartName: LocalSystem
State: 4
------------------------------------------------------------
ServiceName: MSSQL$SQLEXPRESS
Description: Provides storage, processing and controlled access of data and rapid transaction processing.
DisplayName: SQL Server (SQLEXPRESS)
ErrorControl: 1
ExitCode: 1077
HostName: MICROTRAINING
ProcessId: 0
SQLServiceType: 1
StartMode: 3
StartName: NT AUTHORITY\NetworkService
State: 1
------------------------------------------------------------
ServiceName: MSSQLSERVER
Description: Provides storage, processing and controlled access of data and rapid transaction processing.
DisplayName: SQL Server (MSSQLSERVER)
ErrorControl: 1
ExitCode: 0
HostName: MICROTRAINING
ProcessId: 1180
SQLServiceType: 1
StartMode: 2
StartName: LocalSystem
State: 4
------------------------------------------------------------
ServiceName: ReportServer$SQLEXPRESS
Description: Manages, executes, renders, schedules and delivers reports.
DisplayName: SQL Server Reporting Services (SQLEXPRESS)
ErrorControl: 1
ExitCode: 1077
HostName: MICROTRAINING
ProcessId: 0
SQLServiceType: 6
StartMode: 3
StartName: LocalSystem
State: 1
------------------------------------------------------------
ServiceName: SQLBrowser
Description: Provides SQL Server connection information to client computers.
DisplayName: SQL Server Browser
ErrorControl: 1
ExitCode: 0
HostName: MICROTRAINING
ProcessId: 1816
SQLServiceType: 7
StartMode: 2
StartName: NT AUTHORITY\NetworkService
State: 4
------------------------------------------------------------
ServiceName: SQLSERVERAGENT
Description: Executes jobs, monitors SQL Server, and fires alerts, and allows automation of some administrative tasks.
DisplayName: SQL Server Agent (MSSQLSERVER)
ErrorControl: 1
ExitCode: 1077
HostName: MICROTRAINING
ProcessId: 0
SQLServiceType: 2
StartMode: 3
StartName: LocalSystem
State: 1
------------------------------------------------------------

Atasarea unei baze de date

ggciubuc — Mon, 09 Oct 2006 09:15:33 GMT

Atasarea unei baze de date

Atasarea (cu operatia complementara “detasarea”) unei baze de date este o procedura folosita , asa cum ii spune denumirea , pentru inserarea pe server a unei baze de date SQL Server provenita de pe alt sistem.

Detasarea, sau mai degraba pregatirea unei baze de date pentru atasare pe alt server se poate face in 2 feluri :

· -prin interfata, in Management Studio, right-click pe baza de date -> Tasks->Detach…

· Se opreste serviciul SQL Server si se copiaza fisierele de date si log in locatia dorita dupa care se reporneste serviciul.

Operatia inversa , atasarea se poate face tot in 2 feluri astfel:

· Prin interfata , similar;

· Prin lansarea comenzii “CREATE DATABASE …” de undeva dintr-un script , folosind optiunile FOR ATTACH sau FOR ATTACH_REBUILD_LOG

Sa incercam sa studiem problema atasarii unei baze de date in situatia in care ne lipsesc fisierele de log. Aceasta problema reala , a evitarii atasarii logului unei baze de date de productie care a atins dimensiuni mari si-o poate pune echipa de dezvoltare cand vrea sa aiba la dispozitie o baza de date cu date la zi.

Construim o baza de date “chioara” test1 prin interfata, cu un singur fisier de log; o detasam rapid si modificam numele fisierului din “test1_log.ldf” in “test1_log_1.ldf” simuland situatia in care acesta lipseste. Lansam comanda cu optiunea “FOR ATTACH

create database test1 on (name =test1, filename='C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test1.mdf') for attach

Sistemul recreaza fisierul de log iar mesajul corespunzator este urmatorul:

"File activation failure. The physical file name "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test1_log.ldf" may be incorrect.

New log file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test1_log.LDF' was created."

Mai departe adaugam un fisier de log la schema bazei de date si reluam operatia de mai sus simuland pierderea celor 2 fisiere de log. Mesajul care a rezultat este urmatorul :

"File activation failure. The physical file name "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test1_log.ldf" may be incorrect.

File activation failure. The physical file name "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test2_log.ldf" may be incorrect.

The log was not rebuilt because there is more than one log file.

Msg 1813, Level 16, State 2, Line 1

Could not open new database 'test1'. CREATE DATABASE is aborted."

…iar baza de date “test1” nu a fost atasata.

Avem sperante ca optiunea cealalta ne va rezolva problema:

Asa e, jocul nostru cu un singur fisier de log decurge ca mai sus insa pentru partida in care evoluam cu 2 loguri mesajul este urmatorul :

File activation failure. The physical file name "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test1_log.ldf" may be incorrect.

File activation failure. The physical file name "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test12_log.ldf" may be incorrect.

New log file 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test1_log.LDF' was created.

Serverul ataseaza baza de date insa creeaza numai un fisier de log si anume 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\test1_log.LDF' . Asta face necesara realizarea unui backup full imediat al bazei de date deoarece avem o alta schema.

In concluzie, pentru o baza de date , optiunea de atasare/detasare este o solutie buna luat in calcul, cu atentie, asa cum am mentionat mai sus , pentru mutarea din productie la dezvoltare.

Manifest pentru metodologia "Agile"

ggciubuc — Sat, 07 Oct 2006 06:13:55 GMT

Manifest pentru metodologia "Agile"

Mai multe personalitati din Project Management(PM) s-au adunat si au dezbatut
o cale de iesire dintr-un impas al eficientei la care ajunsese PM clasic: s-a constatat ca numai
17% din aplicatiile create ajung sa aiba succes relativ , adica sa fie folosite de beneficiari.
Sau,folosind un exemplu un pic fortat: cate din optiunile Microsoft Word ajung sa fie folosite?Pentru mine ca beneficiar e posibil ca , sa zicem, 20 % din facilitatile Word sa le folosesc, restul nu-mi sunt interesante, producatorul a produs un efort suplimentar. Intr-o aplicatie particulara trebuie sa fie implementate exact acele optiuni folosite: asta scurteaza timpul de executie si beneficiarul este multumit.
Revenind, acestia au schimbat lucrurile si definind o serie de principii care modifica fundamental lucrurile (vezi www.agilemanifesto.org):

1)"Individuals and interactions over processes and tools " - sa asculti ce spune programatorul(creatorul/echipa), el simte si rezolva problema nu procesele si instrumentele utilizate;
2)"Working software over comprehensive documentation " - obiectivul principal e sa mearga aplicatia nu sa rezolvi o caruta de documentatie de proiect;
3)"Customer collaboration over contract negotiation "- sa ai alaturi de tine clientul, dincolo de stipulatiile unui contract care pot bloca proiectul
4)"Responding to change over following a plan " - sa nu fii blocat de un plan ci sa faci modificarile in aplicatie cu tinta satisfactia beneficiarului.

Ce legatura are interventia mea cu SQL-ul, bazele de date ?

Va marturisesc ca am apucat sa aplic principiile enuntate cand am fost nevoit sa conduc un proiect de dezvoltare a unei aplicatii web-based in .Net cu acces la o baza de date SQL 2000.

Si a MERS !

Am proiectat baza de date cu referire numai la informatia de care avea nevoie beneficiarul. Incercand sa fac "Working software" am pornit de la un nucleu al bazei de date care permitea functionarea aplicatiei si asigura un set minim de servicii. Ceea ce m-a determinat sa scriu acest articol este partea a 2 a principiului : "comprehensive documentation" activitate care daca este dusa la extrem mare consumatoare de energie.(Revenind la proiectul de care v-am vorbit va dati seama ca aici a intervenit e un sef care inca nu a auzit de metodologia de fata).

In concluzie recomand cu caldura aceste principii ale agilitatii atunci cand conduceti un proiect software.Iar daca sunteti in echipa, in interiorul ei, la carma bazelor date sau mediului de dezvoltare, deschideti ochii sefului, pentru ca astfel va fi multumit beneficiarul, dvs. pt ca aveti lucruri mai putine si clare de facut si , sigur, pentru ca pot iesi si bani mai multi din asta.

Data Definition Language (DDL) Triggers

xmldeveloper — Tue, 03 Oct 2006 11:11:48 GMT

Data Definition Language (DDL) Triggers

Un DDL trigger (declansator) este activat de instructiuni tip CREATE, ALTER sau DROP atat la nivelul serverului cat si al unei baze de date. Poate fi folosit pentru monitorizare modificarilor intr-o baza de date, blocarea anumitor schimbari sau chiar mentinerea unor standarde de cod in definirea obiectelor. Momentan un DDL trigger este activat doar dupa executia instructiunii DDL – varianta INSTEAD OF (activare in loc de executia instructiunii DDL) nefiind prezenta in versiunea curenta a SQL Server 2005. Functia EVENTDATA poate fi folosita pentru a obtine textul complet al instructiunii executate.

Exemplu:

-- blocheaza instructiunea DROP TABLE

-- la nivelul bazei de date curente

CREATE TRIGGER drop_table_trigger ON DATABASE

FOR DROP_TABLE

PRINT 'Operatie interzisa!'

ROLLBACK

Observatii:

In cazul in care folositi DDL triggers pentru audit, puteti folosi pentru acelasi scop si Notificari de Evenimente (Event Notifications). Diferenta consta in modul de lucru: sincron pentru un DDL trigger si respectiv asincron pentru notificari.
DDL triggers nu functioneaza pentru anumite proceduri sistem ca de exemplu sp_rename.

Conexiune Dedicata pentru Administrator

xmldeveloper — Fri, 06 Oct 2006 08:19:47 GMT

Conexiune Dedicata pentru Administrator

In cazuri deosebite cand accesul la SQL Server nu mai este posibil datorita unor probleme sau unor erori, este disponibila o conexiune pentru membrii rolului sysadmin, prin care se poate face diagnosticare si se pot executa interogari. Aceasta conexiune dedicata administratorului (DAC) se poate face folosind utilitarul din linie de comanda sqlcmd in doua modalitati - cu parametrul de administrator –A, sau folosind numele instantei si prefixul admin: spre exemplu sqlcmd –Sadmin:<nume-instanta>. Dealtfel se poate folosi pentru aceasta conexiune si SQL Server Management Studio Query Editor deschizand o conexiune la admin:<nume-instanta>.

In mod implicit conexiunea se poate face doar de catre un client aflat pe server, dar se poate permite accesul din retea daca se configureaza optiunea remote admin connections cu procedura stocata sp_configure sau aplicatia Surface Area Configuration. Poate exista numai o singura conexiune DAC. Este recomandata conectarea la baza de date master folosind comanda sqlcmd –A –d master, si nu este posibila executia interogarilor in paralel. Aceasta conexiune nu este disponibila implicit in SQL Server 2005 Express Edition insa poate fi activata prin folosirea unui trace flag.

Exemple:

Pentru conectare local folosind portul standard:

sqlcmd –S 127.0.0.1,1434

Pentru conectare prin retea:

sqlcmd –S server_name_or_ip –U sa –P password –A

Detalii suplimentare: http://sqlserver.ro/forums/thread/91.aspx