Romanian SQL Support team blog

Replicarea de tip "merge" folosind date partitionate - concluzii despre performanta

Un scenariu des intalnit de replicare de baze de date de tip „merge” este acela in care un server central SQL Server publica o baza de date catre un numar mare de abonati mobili (ex: PDA-uri cu SQL Server Mobile).

Pentru a raspunde la anumite constrangeri fizice (lipsa de spatiu de stocare pe dispozitivul mobil, banda de retea redusa la conectarea cu serverul central, etc) dar si la eventualele constrangeri de securitate (daca se vrea de exemplu ca fiecare utilizator mobil sa aiba acces doar la datele de care are nevoie, etc) se pot folosi filtre de replicare.

Filtrele de replicare sunt de doua feluri – statice sau dinamice; cele statice filtreaza datele orizontal sau vertical pentru toti abonatii – nu fac diferentierea intre dispozitivele mobile si practic permit excluderea din baza de date replicata a unor linii sau coloane.

Filtrele dinamice permit in schimb particularizarea setului de date in functie de utilizatorul mobil: exista filtre dinamice parametrizate (care folosesc functiile SUSER_SNAME() sau HOST_NAME() pentru a identifica PDAul sau userul care se conecteaza la server) si filtre dinamice de tip join (care stabilesc ce date si din ce tabele vor ajunge la un anumit PDA).

Spre exemplu, in Tabela1 in care exista o coloana NumePDA se poate adauga un filtru parametrizat de tipul: NumePDA = HOST_NAME() ceea ce permite ca la conectarea unui PDA ce are numele „PDA1” acesta sa primeasca doar randurile din tabela care au valoarea PDA1 in coloana NumePDA.

Apoi, se pot defini filtre de tip join care sa lege aceasta tabela cu altele din baza de date, spre exemplu Tabela1.ClientID = Tabela2.ClientID;

In urma folosirii acestor filtre, atunci cand PDAul cu numele PDA1 se conecteaza la serverul central pentru a se sincroniza el va avea acces doar la randurile din Tabela1 care au NumePDA = PDA1 si la cele din Tabela2 care indeplinesc conditia din filtrul join: Tabela1.ClientID = Tabela2.ClientID

Tabela1:

Tabela2:

Evident, in practica filtrele sunt mult mai complexe, in functie de nevoile de business ale clientilor, ceea ce poate duce la penalizari de performanta la momentul sincronizarii.

Ce se intampla in momentul sincronizarii? 

In mod traditional, in SQL Server 2000, la momentul sincronizarii are loc un proces de evaluare a partitiilor care folsoeste functia sp_MSsetupbelongs pentru a determina ce randuri ii corespund fiecarui abonat. Acest lucru presupune parcurgerea tabelelor sistem folosite de replicare si identificarea randurilor care apartin de abonatul care s-a conectat la server.

Incepand cu SQL Server 2005, inca din momentul in care un anumit rand a fost modificat pe serverul central, el se va adauga partitiei corespunzatoare abonatului / abonatilor de care apartine; astfel, se evita calcularea partitiilor si se reduc timpii de sincronizare. Acest sistem (numit partitionare precalculata) este implicit in SQL Server 2005, dar in cazul in care anumite conditii de specificare ale filtrelor nu sunt indeplinite, el nu poate fi folosit si se recurge la metoda de evaluare la momentul sincronizarii.

Articolul http://msdn.microsoft.com/en-us/library/ms151737(SQL.90).aspx explica pe larg in ce conditii nu se pot folosi partitiile precalculate, dar in general acest lucru se intampla cand in filtrul parametrizat nu apar functiile SUSER_SNAME() sau HOST_NAME() explicit, ci functii definite de utilizator (care fac apel la SUSER_SNAME() sau HOST_NAME() ).

In acest caz, la sincronizare se efectueaza procesul de evaluare a partitiilor, iar asta poate dura mult in cazul in care mai multi abonati se conecteaza in acelasi timp, pe serverul central exista foarte multe modificari ale datelor si/sau logica de filtrare este complexa.

Pentru a incerca sa reducem timpul de sincronizare, exista mai multe posibilitati:

1.       Reducerea numarului de agenti ce se conecteaza in acelasi timp (daca este posibil);

2.       Verificarea fragmentarii pt tabelele sistem folosite in procesul de eveluare a partitiilor -> de obicei este bine sa rulam un script de defragmentare pe toate tabelele sistem folosite de replicare, pentru ca acestea se modifica foarte mult atunci cand se executa operatii pe tabelele utilizator;

3.      Modificarea logicii de filtrare (filtrele de tip parametrizat sau cele join) -> acesta este probabil punctul cel mai complicat pentru ca trebuie tinut seama de cerintele de functionare ale aplicatiei. Unele solutii sunt:

-         folosirea SUSER_SNAME() si HOST_NAME() doar in filtrele parametrizate, de prefrinta explicit; aceste functii se pot folosi si in filtrele join sau chiar in cele statice, dar acest lucru este nerecomandat;

-         indexarea coloanelor ce apar in filtrele join;

-         daca una din coloanele ce apar intr-un filtru join au atributul UNIQUE, se seteaza optiunea join unique key pt filtrul respectiv; astfel, se evita cautarea intr-o tabela din momentul in care o valoare corespunzatoare filtrului a fost gasita;

-         in cazul (foarte des intalnit) in care in definitia filtrului apar functii nondeterministe (ca de exemplu GETDATE() ) este recomandat sa adaugam o coloana de tip bit in tabela replicata care sa indice daca un rand trebuie sa nu sa fie replicat. Modificarea bitului se poate face printr-un job SQL Server care va parcurge toata tabela si va marca radnurile ce trebuiesc replicate, iar conditia din filtru se va modifica astfel incat sa referntieze aceasta coloana de tip bit; astfel se evita pe de o parte probleme de performanta, dar si o functionare defectuoasa a aplicatiei: daca in filtru avem conditia WHERE data > (GETDATE() – 1) asta presupune ca ne asteptam ca la urmatoarea rulare a agentului de replicare liniile cu data posterioara datei de ieri sa fie prelucrate de agentul de replicare. In realitate, agentul de replicare va prelucra doar randurile care au fost modificate de la ultima sa rulare, deci va ignora randurile care corespund conditiei din filtru, dar nu s-au modificat! In acest caz, nu s-a schimbat nicio valoare in tabela. Solutia este sa folosim o coloana nou de tip bit care sa fie initializata cu 0, iar in momentul in care detectam ca a trecut o zi, sa modificam valoarea bit-ului in 1; noul filtru de replicare va fi bazat pe aceasta coloana noua: WHERE bit = 1. Articolul http://msdn.microsoft.com/en-us/library/ms365153(SQL.90).aspx da mai multe detalii despre aceasta solutie.

Andreea Vasilescu

How to deploy SQL Server Client Aliases using Active Directory GPO/ADM

1.       On your Domain Controller make sure you have installed the GPMC with SP1

2.       Open GPMC

3.       Create and link a GPO at the Top of the Domain level or inside the Organizational unit containing the computers where you want the alias to be applied 

4.       If you leave the policy at the domain level it will be applied to the entire Domain. If you want to apply the alias only to a part of the domain Computers and do not have all of these computers inside a single OU, you need to remove Authenticated Users from the security Filtering, then click on the Add button from the Security Filtering. Then select the object types to only be Computers, then Advanced, Find and select the computers where you want the policy to be applied. If you have lots of computers where this policy needs to be applied, you can use WMI filtering or LDAP query to put all computers inside a security group and then add the group to the security filtering.

5.       Right click the linked GPO and select Edit

6.       The Group Policy Object Editor Should open

7.       It is now time to create your ADM file using notepad. Create a new file with the ADM extension and put the following code inside it:

CLASS MACHINE

CATEGORY "SQL Server Client aliases"

                KEYNAME "SOFTWARE\Policies"

                POLICY "List of SQL Server aliases"

                               EXPLAIN "This list of SQL Server aliases will be deployed to users which are affected by this GPO !"

                               PART "ALIASLIST"                           LISTBOX

                                               KEYNAME "SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo"

                                               EXPLICITVALUE

                               END PART

                END POLICY

END CATEGORY

8.       In the Group Policy Object Editor, right click the Administrative Templates and choose Add/Remove Templates

9.       Browse to your newly created ADM files and then click close

10.   You should now have the new policy defined. It looks like this:

11.   Double click on the policy, check "Enabled" and then click "Show" :

12.   Because the policy is new, the list is empty. Click "Add" to specify a new Alias.

13.   Inside the NAME you should enter the NAME as used inside your applications to specify the server to connect to. If the connection string inside your applications are only using the machine name you will also only use the machine name. If the con string uses the machinename\instancename you should use the same format.

14.   Inside the VALUE you should enter the new machine name and the new port for the migrated SQL instance. If this is the default instance the port is not required. However you also need to mention DBMSSOCN for the alias to work. So the syntax would be "DBMSSOCN,machinename,sqlinstanceportnumber"

15.   For example let's suppose that one of your applications on a client machine uses the following connection string "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Data Source=sql2005lb1". Then you migrate your SQL instance from machine SQL2005lb1 to machine SQL2005LatestB1 and now the SQL instance is named SQL2005 and it is listening on port 2567. This is how the Add Item text boxes should be filled:

You can also use the new SQL instance name instead of the port number if the port is dynamic. Be careful to have the SQL Browser open on the Server machine in this scenario in order to have the instance name translated into port number. Here is how the Add Item text boxes should be filled in this case:

16.   Everything is not set correctly. Client machines will have to be restarted for the policy to be automatically pushed. They can be manually forced without the need to restart the machine, by running on each client machine the command "gpupdate /force".

Put a windows form on a SharePoint web site

Open Visual Studio 2008, create a new project, chose the template “Windows Forms Control Library”.

Add a button and a textBox on the userControl. Add some text into the textBox when the button is clicked. Build the project. We will copy later the dll file that has been generated.

Open Visual Studio 2008, create a new project, choose SharePoint for project type and WebPart for Template. Drive your class from Microsoft.SharePoint.WebPartPages.WebPart. Override the RenderWebPart method in order to display the object that is your dll.

Put a windows form on a web site

Create the Windows Form Control

Create a “Windows Forms Control Library” project in Visual Studio 2008. For this simple example we will add a Button and a TextBox to the control.

Bazele troubleshooting-ului pentru deadlock - SQL 2005 Server

Bazele troubleshooting-ului pentru deadlock - SQL 2005 Server

Deadlock-ul apare atunci cand doua sau mai multe SPID-uri se blocheaza unul  pe altul si niciunul nu mai poate fi procesat. Cand mecanismul motorului SQL Server detecteaza un deadlock, unul dintre SPID-uri este ales ca victima si este anulat generand errori de tipul 1205. Erorile pot fi inregistrate in fisierul ErorLog.txt iar transactia SPID-ului anulat este supusa actiunii de roll-back.

Deadlocking-ul poate fi verificat prin urmatoarele elemente:

1.       SQL Profiler - capturarea unui trace SQL Profiler dar care nu impacteaza performata masinii (evitarea capturii pe un share pe reatea, evitarea capturarii a unor evenimente cu frecventa mare ca Object:Opened, Lock:Acquired/Released, etc., utilizarea unui template Profiler: GeneralPerformance template, utilizarea de filtre in Profiler Trace pentru a reduce volumul capturii, etc)

2.       Activarea traceFlagul-ui 1222 care permite vizualizarea detaliilor legate de blocking fisierele erorlog.txt.

Activarea se face prin executarea codului T_SQL :"DBCC TRACEON (1222, -1)".

3.       Colectarea fisierelor Erorlog.txt dupa ce un deadlocking a fost reprodus.

Exemplu de deadlocking capturat in ErrorLog:

deadlock-list

 deadlock victim=processdceda8

  process-list

   process id=processdceda8 taskpriority=0 logused=0 waitresource=KEY: 2:72057594051493888 (0400a4427a09) waittime=5000 ownerId=24008914 transactionname=SELECT lasttranstarted=2006-09-08T15:54:22.327 XDES=0x8fd9a848 lockMode=S schedulerid=1 kpid=4404 status=suspended spid=54 sbid=0 ecid=0 priority=0 transcount=0 lastbatchstarted=2006-09-08T15:54:22.293 lastbatchcompleted=2006-09-08T15:54:22.293 clientapp=OSQL-32 hostname=BARTD2 hostpid=3408 loginname=bartd isolationlevel=read committed (2) xactid=24008914 currentdb=2 lockTimeout=4294967295 clientoption1=538968096 clientoption2=128056

    executionStack

     frame procname=tempdb.dbo.p1 line=2 stmtstart=60 sqlhandle=0x03000200268be70bd

       SELECT c2, c3 FROM t1 WHERE c2 = @p1    

     frame procname=adhoc line=2 stmtstart=32 stmtend=52 sqlhandle=0x020000008a4df52d3

       EXEC p1 3    

    inputbuf

       EXEC p1 3

   process id=process3c54c58 taskpriority=0 logused=16952 waitresource=KEY: 2:72057594051559424 (0900fefcd2fe) waittime=5000 ownerId=24008903 transactionname=UPDATE lasttranstarted=2006-09-08T15:54:22.327 XDES=0x802ecdd0 lockMode=X schedulerid=2 kpid=4420 status=suspended spid=55 sbid=0 ecid=0 priority=0 transcount=2 lastbatchstarted=2006-09-08T15:54:22.327 lastbatchcompleted=2006-09-08T15:54:22.310 clientapp=OSQL-32 hostname=BARTD2 hostpid=2728 loginname=bartd isolationlevel=read committed (2) xactid=24008903 currentdb=2 lockTimeout=4294967295 clientoption1=538968096 clientoption2=128056

    executionStack

     frame procname=tempdb.dbo.p2 line=2 stmtstart=58 sqlhandle=0x030002005fafdb0c

       UPDATE t1 SET c1 = FLOOR (c1), c2 = FLOOR (c2) WHERE c1 = @p1    

     frame procname=adhoc line=2 stmtstart=32 stmtend=52 sqlhandle=0x020000006f878816

       EXEC p2 3    

    inputbuf

       EXEC p2 3

  resource-list

   keylock hobtid=72057594051559424 dbid=2 objectname=tempdb.dbo.t1 indexname=idx1 id=lock83642a00 mode=S associatedObjectId=72057594051559424

    owner-list

     owner id=processdceda8 mode=S

    waiter-list

     waiter id=process3c54c58 mode=X requestType=wait

   keylock hobtid=72057594051493888 dbid=2 objectname=tempdb.dbo.t1 indexname=cidx id=lock83643780 mode=X associatedObjectId=72057594051493888

    owner-list

     owner id=process3c54c58 mode=X

    waiter-list

     waiter id=processdceda8 mode=S requestType=wait

4.       Un alt element important este Statistics Clone Copy a bazei de date.

Troubleshooting:

1.       In SQL Profiler Trace se identifica query-urile care genereaza deadlocking.  

Verificati daca deadlocking-ul nu se incadreaza in articolul KB: You may receive error message 8650 when you run a query that uses intra-query parallelism<http://support.microsoft.com/kb/837983>

2.       Asigurati-va ca se foloseste minumul necesar de trasaction isolation level

3.       Query-urile implicate in deadlocking trebuies supuse tool-urilor Index Tunning Advisor si  Database tuning Advisor. Agaugati index-urile recomandate de aceste tool-uri . Mai mult de jumatate din cazurile de deadlocking sunt rezolvate cu Index Tuning Advisor.

Cum trebuie configurat un Job SQL 2005 Server Integration Services via SQL Server Agent sa execute un Maintenance Plan creat ca un package SSIS in SQL 2005 Server

Cum trebuie configurat un Job SQL 2005 Server Integration Services via SQL Server Agent sa execute un Maintenance Plan creat ca un package SSIS in SQL 2005 Server 

Aceasta fisa tehnica prezintă configurarea unui Job SQL 2005 Server Integration Services (SSIS) care executa un Maintanance Plan. In multe cazuri rularea Maintanance Plan-ului intr-un Job SSIS creat manual nu aduce rezultatul dorit. In acest articol vom lua ca exemplu un Maintanance Plan care executa un backup pentru fisierele unei baze de date.

        I.            Crearea unui Maintance Plan in SQL 2005 Server:

Pentru crearea unui Maintance Plan apasati Right Click pe folderul Management in consola Microsoft SQL Management Sudio si alegeți New Maitanance Plan. In fereastra care se deschide alegi un nume (in exemplu de fata am ales BackupMaintenancePlan).

             http://blogs.msdn.com/photos/sqlro/images/9523024/original.aspx

             http://blogs.msdn.com/photos/sqlro/images/9523023/original.aspx

Mai departe vom alege un Task pentru Maintance Plan-ul creat. Acest lucru se realizează prin Drag and Drop un Task din lista din partea stânga jos a ecranului.

            http://blogs.msdn.com/photos/sqlro/images/9523027/original.aspx 

Un dublu click pe blocul Back Up Database Task ne permite deschiderea unei ferestre de configurare a Task-ului. Vom alege AdventureWoks ca baza de date ținta pentru backup.

            http://blogs.msdn.com/photos/sqlro/images/9523028/original.aspx

            http://blogs.msdn.com/photos/sqlro/images/9523025/original.aspx

Salvați noul Maintance Plan creat si înainte de al executa asigurați-va ca serviciul SQL Server Agent est pornit.

            http://blogs.msdn.com/photos/sqlro/images/9523026/original.aspx

Planul poate fi executat prin Right Click pe numele Maintance Plan-ului in folderul Management -> Execute.

            http://blogs.msdn.com/photos/sqlro/images/9523030/original.aspx

            http://blogs.msdn.com/photos/sqlro/images/9523029/original.aspx

Odată executarea terminata, verificați crearea fișierului de backup AdventureWorks_backup_XXXXXXXXX.bak in directorul

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup

(acesta este directorul propus by default). Daca fisierul de backup exista putem trece la pasul următor.

Nota: Daca explorați SQL Server Agent veți remarca in folderul Jobs crearea unui job cu numele BackupMaintenancePlan.Subplan_1, unde Subplan_1 este numele subplan-ului din Maintance Plan creat mai sus. Acest nume de tipul Subplan_x este numele by default care il iau toate subplan-urile definite in Maintance Plan. Exista posibilitatea de a schimba numele pentru fiecare subplan după cum doriți.

http://blogs.msdn.com/photos/sqlro/images/9523031/original.aspx

      II.            Configurarea unui job SSIS care executa Maintenance Plan.

Complexitatea proiectului poate necesita crearea unui Job SSIS care sa execute in același timp mai multe Maintenance Plan-uri si intr-o anumita ordine.  Ne vom ocupa in continuare de crearea manuala a unui Job SSIS care executa un Maintance Plan deja existent. Ca exemplu vom lua Maintenance Plan-ul creat mai devreme care are ca rezultat un backup pentru o baza de date.

Pentru crearea unui job SSIS apăsați right click pe folderul SQL Server Agent Jobs si alegeți New Job. In fereastra apăruta alegeți numele noului Job SSIS sub pagina General. (exemplu: CustomBackupJob)

      http://blogs.msdn.com/photos/sqlro/images/9523035/original.aspx

Sub pagina Steps se definește Maintenance Plan-ul care trebuie executat. Apăsați butonul New si in fereastra care se deschide trebuie configurate următoarele:

1)            Numele Step-ului (exemplu: Step CustomeBackupJob).

2)            Tipul step-ului (exemplul nostru:  SQL Server Integration Package).

3)            Contul sub care trebuie executat( by default: SQL Agent Service Account).

4)            In Tab-ul general trebuie indicata sursa packet-ului (SQL  Server) si calea sursa a acestuia(in exemplul nostru \Maintenance Plans\BackupMaintenancePlan).

http://blogs.msdn.com/photos/sqlro/images/9523032/original.aspx

In acest moment Job-ul poate fi executat cu succes insa fisierul de backup al planului de mentenanta nu va fi creat. Aceast inconvenient este by design pentru toate planurile de mentenanta create ca packete SSIS. subplan-ul (in exemplul nostru subplan_1) este in statut Disable by defoult. Acestea sunt in statut Enable doar in timpul executiei care impune parametrii specifici. Totusi pentru a putea rula joburi create manual care executa planuri de mentenanta trebui facuta urmatoarea modificare in Proprietatile Step-ului care contine packetul SSIS (planul de mentananta).

5)         Configurarea Tab-ului SetValues

Ne întoarcem la configurarea Job-ui. In Tab-ul Set Values din fereastra care prezintă proprietățile Step-ului, in coloana Property Path trebuie introdusa următoarea valoare: Package\Subplan_1.Disable, iar in coloana Value : FALSE.

 http://blogs.msdn.com/photos/sqlro/images/9523089/original.aspx

Radu Nita

Configurare HTTP necesara pentru accesul la un Server Analysis Services 2005 care ruleaza pe Windows Server 2003

Acest continut este destinat acelora care doresc sa acceseze SQL 2005 Server Analysis Services  prin protocolul  HTTP. Ma departe sunt  explicati pasii necesari parametrarii accesului HTTP si subiecte legate de securitatea acestuia (se aplica pentru Windows Server 2003).

Microsoft Server 2005 Analysis Services utilizeaza  aceeasi arhitectura ca Microsoft Server 2000 Analysis Services  pentru a furniza access HTTP. Componentul pump este incarcat in IIS si este folosit ca si extensie ISAPI extention asigurand transferul client - Analysis Services  si invers. Mai departe gasiti explicatii pentru parametrarea accesului HTTP spre Microsoft Server 2005 Analysis Services care ruleaza pe o masina  Windows Server 2003.

 http://blogs.msdn.com/photos/sqlro/picture9380719.aspx

Configurarea Binarelor:

                Trebuie copiat contunutul directorului  %Director Setup%\OLAP\bin\isapi intr-un director care o sa devina, mai tarziu, baza pentru directorul virtual in IIS.

Exemplu:

Copiati folderul C:\Program Files\Microsoft SQL Server\MSSQL.1\OLAP\bin\isapi in interiorul C:\inetpub\wwwroot\olap

                Conditii de respectat:          

                                                -  directorul virtual trebuie sa fie pe un volum formatat NTFS

                                                 - calea directorului sa nu contina spatii (conditie IIS)

                                                 - este necesara  instalarea  OLEDB for Analysis Redistributable package daca intentionati sa instalati HTTP pump pe un alt server decat cel pe care ruleaza AS.

Crearea unui Application Pool:

                1)            In consola Computer Management (Control Panel -> Administrative Tools-> Computer Management),  mergeti la nodul Services and Applications, apoi la nodul IIS.

Conditie:                - daca  Internet Information Services  nu exista atunci trebuie instalat (Control Panel -> Add or Remove Programs -> Add/Remove Window Components -> Components -> Application Server)

 http://blogs.msdn.com/photos/sqlro/picture9380719.aspx

                2)            Deschideti consola Computer Management sub Administrave Tools. In Applications node mergeti la nodul Internet Information Services.

                3)            Click dreapta pe Application pools si alegeti New, Application pool. Alegeti un nume pentru Application pool ID (exemplu: OLAP).

Creearea Virtual Directory-ului:

                1)            In consola Computer Management (Control Panel -> Administrative Tools-> Computer Management),  mergeti la nodul Services and Applications, apoi la nodul IIS.

                2)            Click dreapta pe Web site pentru a deschide. Apoi alegeti New -> Virtual Directory. Alegeti un nume pentru Virtual Directory(exemplu: OLAP).

 http://blogs.msdn.com/photos/sqlro/picture9380722.aspx

 Continutul  directorului trebuie sa fie fixat in folderul declarat mai sus.

                In exemplul nostru : C:\inetpub\wwroot\olap.

                                3)            Asigurati-va ca in fereatra Access Permissions, singura casuta bifata este Run Scripts (Such as ASP).

 Setarea propietatilor :

                1)            Click dreapta pe nodul Virtual Directory si alegeti Properties. Aici trebuie schimbate urmatoarele:

                                - Pentru campul Application Pool introduceti ID deja creat.

                                - Apasati butonul Configuration, apoi Add. In campul Executable introduceti calea catre msmdpump.dll ( exemplu:C:\wwroot\olap\msmdpump.dll). In campul Extension introduceti  <.dll> . Apoi click OK.

http://blogs.msdn.com/photos/sqlro/picture9380723.aspx 

http://blogs.msdn.com/photos/sqlro/picture9380724.aspx  

 Setarea Securitatii:

In Properties pentru Virtual Directory, sub tab-ul Directory Security, click Edit pe Authentication and access control.

                Anonymous access

                                Daca acest mod este selectat, msmdpump.dll ruleaza cu credentiale pentru User name din campul de mai jos. Notati ca orice conexiune la Analysis Services se face cu acest user. In general, acest mod trebuie folosit cand infrastuctura de securitate nu foloseste functionalitatea  de securitate din Analysis Services.

                Integrated Windows authentication

                                Acest mod este cel mai recomandat.

                Digest authentication for Windows domain servers

                                Pentru detalii despre acest mod consultati IIS.

                Basic authentication

                                Acest mod permite introscerea unui User name si parolei desemnate acestuia. Acestea sunt transmise prin conexiunea HTTP la IIS. De aici, IIS incearca impersonarea utilizatorului pe baza credentialelor. De asemenea, IIS permite o alta cale foarte sigura de transmitere a credentialelor(HTTPS). Acest mod permite conectarea la Serverul Analysis services din afara domeniului folosing de expemplu un fishier Excel.

http://blogs.msdn.com/photos/sqlro/picture9380725.aspx

Setarea extensiei Web Service:

                1)            In consola Computer Management, click dreapta nodul Web Service Extensions si alegeti Add new Web Service Extension. Algeti un nume pentru extensie(exemplu: OLAP)

                2)            Apasati butonul Add pentru a configura calea spre msmdpump.dll. Bifati casuta Set extension status to Allowed check box.

http://blogs.msdn.com/photos/sqlro/picture9380726.aspx

Alegerea Server-ului Analysis Services tinta:

Trebuie specificat faptul ca fiecare component pump utiliseaza fisierul care i-a fost configurat conform primei figuri, la inceputul articolului.

Pentru a indica serverul tinta, deschideti fisierul msmdpump.ini. In interiorul acestui fisier <ServerName> este paramatrul care desemneaza server-ul la care se face conectarea. Daca instanta de Analysis Sercices de care aveti nevoie se gaseste pe o masina locala si reprezinta instanta default nu aveti niciun motiv sa modificati valoarea pentru <ServerName>. Altfel, trebuie sa specificati numele masinii si numele instantei ( exemplu: mymachine\inst1).

Conecatrea din applicatie:

Daca aplicatia folosita va permite specificarea server-ului, nu va ramane decat sa folositi pentru paramatrare calea Virtual Directory-ului concatenat cu fisierul “msmdpump.dll”.

by radu nita