Tesi_Manfrin

UNIVERSITÀ DEGLI STUDI DI TRIESTE

An application to manage and automatecommon procedures in a server farm

LAUREANDO RELATORE

Paolo Manfrin Chiar.mo Prof. Alberto Bartoli

A.A. 2007/2008

Ringraziamenti

Desidero ringraziare quanti hanno contribuito alla mia formazione e allarealizzazione di questa tesi.

In particolare ringrazio il Professor Bartoli Alberto per la revisionecritica di questa tesi, tutto il Dipartimento di SAP Business One, i TeamLeaders Valerie Maybin e Karen Martinez nonchè il Project ManagerAurelien Leblond. Ringrazio inoltre la Dott.ssa Mundt per i preziosisuggerimenti inerenti le basi dati di SAP Business One.

Concludo ringraziando la mamma Gabriella, il papà Eligio e la nonnaMaria per il sostegno durante l’intera carriera universitaria.

iii

Indice

1 Introduzione 1

2 Analisi 32.1 Descrizione del Problema . . . . . . . . . . . . . . . . . . 3

2.1.1 Contesto Aziendale . . . . . . . . . . . . . . . . . . 32.1.2 Overview Sistemi ed Entità . . . . . . . . . . . . . 42.1.3 Pratica Interna . . . . . . . . . . . . . . . . . . . . 42.1.4 Software Preesistente . . . . . . . . . . . . . . . . . 6

2.2 Analisi del Problema . . . . . . . . . . . . . . . . . . . . . 62.2.1 Definizione del Problema . . . . . . . . . . . . . . . 7

2.3 Analisi dei Requisiti . . . . . . . . . . . . . . . . . . . . . 82.3.1 Vincoli di progetto . . . . . . . . . . . . . . . . . . 82.3.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 Planning delle attività . . . . . . . . . . . . . . . . 10

3 Progetto del Sistema 113.1 Moduli A e B: Generic Query . . . . . . . . . . . . . . . . 11

3.1.1 Il canale di comunicazione . . . . . . . . . . . . . . 113.1.2 Il Server Listener . . . . . . . . . . . . . . . . . . . 133.1.3 La Base Dati . . . . . . . . . . . . . . . . . . . . . 143.1.4 L’interfaccia Properties Framework . . . . . . . . . 19

3.2 Modulo C: Backup Manager . . . . . . . . . . . . . . . . . 223.2.1 La Procedura di Restore attuale . . . . . . . . . . 243.2.2 Problemi Rilevati . . . . . . . . . . . . . . . . . . . 243.2.3 Possibili Soluzioni . . . . . . . . . . . . . . . . . . 263.2.4 Schema E-R Backup Manager . . . . . . . . . . . . 27

3.3 Modulo D: Ridefinizione GSC Workflow . . . . . . . . . . 27

v

INDICE vi

4 Implementazione 334.1 Moduli A e B . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.1 Properties Framework . . . . . . . . . . . . . . . . 334.1.2 Gli oggetti serializzabili . . . . . . . . . . . . . . . 344.1.3 Server Listener . . . . . . . . . . . . . . . . . . . . 364.1.4 Schema Logico Database (Schema Properties) . . . 384.1.5 Stored Procedures . . . . . . . . . . . . . . . . . . 384.1.6 Indici . . . . . . . . . . . . . . . . . . . . . . . . . 424.1.7 Triggers e Jobs . . . . . . . . . . . . . . . . . . . . 454.1.8 Transazioni . . . . . . . . . . . . . . . . . . . . . . 474.1.9 IO Risultati da server . . . . . . . . . . . . . . . . 50

4.2 MODULO C . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.1 Applicazione BackupManager . . . . . . . . . . . . 534.2.2 Shrink Distribuito . . . . . . . . . . . . . . . . . . 534.2.3 Schema Logico Database (Schema BackupManager) 58

4.3 MODULO D . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Risultati ottenuti 655.1 Moduli A e B . . . . . . . . . . . . . . . . . . . . . . . . . 655.2 Modulo C . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3 Modulo D . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6 Conclusioni e Raccomandazioni 716.1 Miglioramenti moduli A e B . . . . . . . . . . . . . . . . . 716.2 Miglioramenti modulo C . . . . . . . . . . . . . . . . . . . 726.3 Considerazioni Finali . . . . . . . . . . . . . . . . . . . . . 72

A Raccolta Informazioni per la gestione query 73

B Elenco degli script realizzati 75

C Struttura base del Listener 79

D Setup dell’ambiente di test e sviluppo 81

E Interfacce Utente Applicativi 85

F Elenco dei server gestiti 91

Acronimi 95

Elenco delle figure

2.1 Business One Workflow . . . . . . . . . . . . . . . . . . . 42.2 Business One System Overview . . . . . . . . . . . . . . . 52.3 Use Case del Sistema . . . . . . . . . . . . . . . . . . . . . 9

3.1 Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Listener . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Properties Framework . . . . . . . . . . . . . . . . . . . . 143.4 Modello di Accesso ai dati . . . . . . . . . . . . . . . . . . 163.5 Schema definiti nel database TEC . . . . . . . . . . . . . . 193.6 Modello E-R Schema Properties . . . . . . . . . . . . . . . 203.7 Servizi Offerti da Properties Framework . . . . . . . . . . 213.8 Numero database ripristinati su server . . . . . . . . . . . 233.9 Totale spazio annualmente allocato sui server . . . . . . . 233.10 TEC 3 - GUI Richiesta ticket . . . . . . . . . . . . . . . . 253.11 Snapshot Sequoia . . . . . . . . . . . . . . . . . . . . . . . 273.12 Overview Backup Manager . . . . . . . . . . . . . . . . . 283.13 Modello E-R Schema BackupManager . . . . . . . . . . . 293.14 Workflow Attuale . . . . . . . . . . . . . . . . . . . . . . . 303.15 Workflow Ridefinito . . . . . . . . . . . . . . . . . . . . . 31

4.1 Interfaccia PropertiesFramework e sua implementazione . 354.2 Oggetti Serializzabili . . . . . . . . . . . . . . . . . . . . . 374.3 Servizi offerti dal Server Listener . . . . . . . . . . . . . . 394.4 Schema Logico DB (Schema Properties) . . . . . . . . . . 404.5 Stored Procedure GetRemoteQueryResult . . . . . . . . . 424.6 Stored Procedure GetSavedQueryResult . . . . . . . . . . 434.7 Livelli di Isolamenteo [16] . . . . . . . . . . . . . . . . . . 474.8 Interfaccia con la Base Dati per Backup Manager . . . . . 534.9 Interfacce e Implementazioni per Backup Manager . . . . 544.10 Schema Logico DB (Schema BackupManager) . . . . . . . 59

vii

ELENCO DELLE FIGURE viii

4.11 Directories orfane . . . . . . . . . . . . . . . . . . . . . . . 604.12 DBs non associati a Tickets . . . . . . . . . . . . . . . . . 61

5.1 Snapshot Sequoia dopo lo shrink e l’eliminazione delle cartelle orfane 665.2 Database ripristinati (media mobile su 45 gg) . . . . . . . 675.3 Database cancellati (media mobile su 45 gg) . . . . . . . . 675.4 Guadagno di spazio (in %) sui server di backend . . . . . 685.5 Ticket richiesti e ripristini manuali . . . . . . . . . . . . . 69

D.1 Configurazione SSMS . . . . . . . . . . . . . . . . . . . . . 82

E.1 GUI QueryProcessor . . . . . . . . . . . . . . . . . . . . . 85E.2 GUI ResultAnalyzer . . . . . . . . . . . . . . . . . . . . . 86E.3 GUI ServerManager . . . . . . . . . . . . . . . . . . . . . 87E.4 GUI AdminQueries . . . . . . . . . . . . . . . . . . . . . . 87E.5 GUI DisplayQueriesPlugin . . . . . . . . . . . . . . . . . . 88E.6 GUI IVUAutomation . . . . . . . . . . . . . . . . . . . . . 88

Elenco delle tabelle

3.1 Tabella Query . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Tabella Result . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Tabella Batch . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 Tabella Relazioni . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Analisi delle Transazioni . . . . . . . . . . . . . . . . . . . 49

ix

Capitolo 1Introduzione

L’ottimizzazione delle risorse, la riduzione dei costi e l’aumento dellacapacità produttiva aziendale, sono di particolare interesse, specialmentein momenti di crisi economica come quello che stiamo vivendo in questianni.

Questa tesi è stata sviluppata presso il SAP Global Support Center diSAP Business One, in Irlanda, al fine di migliorare il processo di supportofornito dai consulenti SAP durante le fasi di rilevamento e correzione deimalfunzionamenti sui database dei clienti. La tesi è stata sviluppata pa-rallelamente alla attività di tirocinio di 6 mesi svolto a Galway, dedicata aprendere familiarità con il prodotto SAP Business One approfondendo inparticolare i moduli Business Core (SBO-BC), Upgrade (SBO-BC-UPG)ed AddOn (SBO-BC-ADD) di SAP Business One.

Il Global Support Center è composto da consulenti SAP con cono-scenze specifiche relative all’ERP Sap Business One. Business One sibasa su un database relazionale di elevata complessità, la cui strutturainterna è descritta in [1]. Il Global Support Center offre supporto 24 x 7 alivello mondiale, risolvendo i malfunzionamenti sulla base dati in produ-zione presso i clienti SAP, che compromettono la produttività aziendale. Idatabase aziendali possono essere trasferiti in uno dei server SAP localiz-zati in Germania, dove vengono ripristinati per condurre analisi off-line.I server SAP contengono tipicamente 1800 database.

I problemi affrontati in questa tesi sono stati i seguenti:

• semplificare la modalità con cui i consulenti si connettono alle ba-se dati remote in Germania, dalle sedi in Irlanda, Israele, Slovac-chia, Cina, India, e Canada ed eseguono query non note a priori,salvandone i risultati per analisi successive.

1

1. Introduzione 2

• fornire agli altri sviluppatori una interfaccia che consenta di au-tomatizzare routine durante le procedure di backup, upgrade eispezione dei database clienti

• migliorare la gestione della server farm riducendo i crash di sistemache avvengono durante le operazioni di download e ripristino deidatabase clienti

Alcuni dei moduli sviluppati fanno già parte dell’applicativo Test En-vironement Center 4.0, attualmente in fase di sviluppo dall’ SDK Teamdi SAP Business One. Altri verranno integrati in un secondo momento,una volta ultimata la fase di testing. Il nuovo applicativo, già in uso daalcuni consulenti pilota, andrà a sostituire il precedente nei prossimi mesie verrà esteso a tutte le sedi di supporto di SAP Business One.

Durante lo sviluppo della tesi, a stretto contatto con i consulentiSAP, si è inoltre evidenziato un possibile miglioramento produttivo rag-giungibile modificando il workflow attualmente in essere. Tale modificaè stata proposta al SAP System Leader, il quale sta valutando le risorseda destinare alla implementazione della soluzione proposta.

Per quanto concerne il raggiungimento degli obiettivi, i consulentisono ora in grado di eseguire query, senza la necessità di ricorrere a MSSql Server Management Studio come dovevano fare in precedenza, nellamaggior parte dei casi.

L’interfaccia software creata consente agli sviluppatori di interagirecon le basi dati senza la necessità di conoscerne i dettagli come la loca-lizzazione fisica sui server e le stringhe di connessione, consentendo lorodi rimanere concentrati nei moduli che devono sviluppare.

Le problematiche di cui soffriva la server farm sono state in parterisolte introducendo l’operazione di shrinking sui database e cambiandoi parametri relativi alle stored procedures di eliminazione dei database.

Gli applicativi software utilizzati sono stati Visual Studio 2005, SqlServer 2000, Sql Server 2005, Sql Profiler, Tortoise SVN per la gestione delversioning, Sequoia e SAP Business One. Il linguaggi di programmazioneutilizzati sono stati C# e Sql.

Il capitolo 2 inizia discutendo i problemi da risolvere, l’analisi deirequisiti ed i casi d’uso. Il capitolo 3 riporta il progetto del sistema e dellabase dati, seguito dal capitolo 4 in cui viene descritta l’implementazionedel sistema. La trattazione continua con il capitolo 5 in cui vengonoanalizzati i risultati e si conclude nel capitolo 6 con la proposta di ulteriorimiglioramenti.

Capitolo 2Analisi

2.1 Descrizione del Problema

Per poter identificare le problematiche da risolvere è stato necessario com-prendere chiaramente l’organizzazione aziendale e come i vari dipartimen-ti interagiscono tra loro. Tale analisi risulterà di particolare importanzaspecialmente per la fase di progettazione della base dati e la modifica delworkflow.

2.1.1 Contesto Aziendale

Questo capitolo descrive come il Dipartimento di SAP Business One èorganizzato per fornire supporto all’utente finale. Possiamo identificare4 attori principali all’interno di Business One (B1):

• L’Utente Finale: è una azienda che usa il prodotto SAP BusinessOne come Enterprise Resource Planning (ERP)

• Il partner SAP: è un rivenditore/consulente punto di contatto peril cliente. Quando un utente finale ha qualche problema con B1contatta il partner il quale ha il compito di valutare il problemasollevato dal cliente

• Il SAP Global Support Center (GSC): è una unità interna a SAPB1 che supporta i partner quando essi non sono in grado di risol-vere un problema. Il partner in questo caso contatta il GSC perdiscutere la problematica incontrata dal cliente. Il GSC è diviso indifferenti sezioni (System, Finance, Logistic, ...) ognuna delle qualioffre supporto per differenti aree di B1. GSC offre supporto 24 x7. Le sedi GSC sono situate in Irlanda (sede principale), Israele,Slovacchia, Cina, India e Canada.

3

2. Analisi 4

• L’ Install Base Development (IBD): IBD è il dipartimento più inter-no che ha il compito di correggere bugs e malfunzionamenti. GSCfa usi di Internal Notes che spiegano come affrontare e risolvere pro-blematiche ricorrenti. Quando il GSC Consultant non è in gradodi risolvere una problematica o scopre o sospetta un nuovo bug,egli lo inoltra in IBD per una analisi più approfondita. Una voltache il problema è risolto esso viene ritornato indietro nella catenadall’IBD al GSC, al Partner SAP e fino al cliente finale.

Le interfacce sono di tipo 1-1 tra cliente finale e Partner SAP, PartnerSAP e GSC, GSC e IBD come illustrato in figura 2.1.

END CUSTOMER

SAP PARTNER GSC IBD

Figura 2.1: Business One Workflow

2.1.2 Overview Sistemi ed Entità

Nello schema di figura 2.2 sono presentati gli attori e i sistemi utiliz-zati. Più COMPANY-DB sono ripristinati sul medesimo TEC 1 server.Tutti i COMPANY-DB ripristinati sulla medesima istanza devono esse-re compatibili con l’SBO-COMMON di quella istanza. I server vengonomantenuti tramite le informazioni registrate nel database TEC Applica-tion Server. Il TEC Application Server è la base di informazioni perapplicativo TEC. I consulenti GSC e IBD utilizzano sia Customer Sup-port System New (CSN) 2 per il tracking del problema da risolvere cheTest Environment Center (TEC) per il download e restore dei databa-se dei clienti. I partner SAP hanno accesso esclusivamente al CSN perinserire messaggi e controllare lo stato di risoluzione.

2.1.3 Pratica Interna

Per meglio comprendere il resto della trattazione, vengono qui descritti iconcetti principali circa la struttura di SAP Business One di particolareimportanza per la definizione della base dati.

1TEC: acronimo di Test Environment Center, l’applicativo utilizzato per ri-pristinare i database inviati dai Partner SAP, effettuare upgrade e salvare ibackup.

2CSN: Applicativo usato da Parner SAP, GSC ed IBD per comunicare e seguirel’evolvere della soluzione al problema inoltrato dal partner. Tutte le comunicazioniufficiali, gli aggiornamenti, la proposta di soluzione e gli allegati vengono gestiti tramitetale applicativo.

5 Descrizione del Problema

COMPANY-DB

SBO-COMMON

COMPANY-DB

TEC Appication Server

TEC Server

TEC Server

TEC Application

CSN Application

GSC

IBD

Patch Level (PL)

Version (V)

Db Type

Patch Level (PL)

Version (V)

Db Type

FTP Server

DOWNLOAD & RESTORE

PARTNER SAP

CSN MessageTEC Ticket

GERMANY (WALLDORF) WORLDWIDE

Figura 2.2: Business One System OverviewLe frecce azzurre indicano gli applicativi utilizzati dall’IBD.Le frecce rosse indicano gli applicativi utilizzati dal GSC.

La freccia nera individua l’applicativo utilizzato dal partner SAP.

SAP Business One è un ERP per piccole medie aziende (fino a 100clients) con architettura client/server 2 tiers. Tale architettura usa il pre-sentation client per far eseguire la logica applicativa e si basa su un servercondiviso per il mantenimento dei dati. I database attualmente suppor-tati sono Microsoft SQL Server 2005 e IBM DB2. Versioni precedentieseguivano invece su SQL Server 2000 [3].

B1 si basa su due database:

• SBO-COMMON che contiene impostazioni di default e pacchetti diinstallazione per una certa versione di SAP B1.

• COMPANY-DB contenente i dati cliente.

Si noti che più COMPANY-DB possono condividere lo stesso SBO-COMMON.L’unico requisito è che la versione (V) e la Patch Level (PL) dei due siala medesima.

Una istanza di SAP B1 è completamente definita dalla versione, lapatch level e il tipo di database (SQL 2000, SQL 2005, DB2).

I GSC Consultant usano attualmente un applicativo chiamato CSNdove possono vedere i messaggi inseriti dai partner (ogni partner è iden-tificato da un identificativo). Dopo che il messaggio è stato inserito nel

2. Analisi 6

CSN esso può essere inoltrato da consulente a consulente allo stesso livello(ad esempio da un consulente GSC ad un altro consulente GSC) oppurepuò essere inoltrato ad un altro livello (verso l’interno: IBD, verso l’e-sterno: Partner). Il messaggio rappresenta il centro di tutto il sistema inquanto raccoglie tutte le informazioni relative al cliente (Customer ID,...), il Partner (Partner ID, ...), la versione di B1 (V, PL, DB type).

Quando il GSC Consultant comincia a risolvere un messaggio, egli hala possibilità di connettersi remotamente al partner o al cliente per ana-lizzare il problema. Nel caso in cui non sia possibile fornire una soluzioneda remoto, allora il partner deve trasferire il backup delCOMPANY-DB in una cartella SFTP assegnata dal consulente.

Una volta caricato il DB, il consulente GSC registra il messaggio nelTEC. TEC è un applicativo usato per importare i COMPANY-DB inviatidai partner nel corretto SAP server, dove i consulenti possono fare il logine risolvere i problemi che affettano la base dati.

Spesso si richiede (specialmente per i membri del System Team) di ese-guire determinate query nel database. Le informazioni relative al servere alla base dati a cui connettersi sono salvate in TEC.

2.1.4 Software Preesistente

I software attualmente in uso dal GSC sono:

• CSN (basato su SAP R3)

• TEC 3.0 (a breve sostituito da TEC 4.0 in sviluppo)

• Microsoft Sql Server Management Studio (MS SSMS)

è importante sottolineare che l’ambiente TEC è designato per supportaresolamente database MS Sql Server dato il numero elevato di installa-zioni, comparate a quelle di IBM Database2 DBMS (DB2). TEC 3.0 èattualmente basato su infrastruttura CITRIX-Metaframe [14].

Tutti i server MS Sql Server 2003 sono localizzati a Walldorf, in Ger-mania e sono accessibili globalmente tramite Virtual Private Network(VPN) da tutte le sedi B1.

2.2 Analisi del Problema

Il seguente capitolo presenterà solamente i moduli sviluppati. Per unadiscussione più generale si rimanda alla lettura di [2]

7 Analisi del Problema

2.2.1 Definizione del Problema

L’Azienda ha identificato i seguenti problemi, che dovevano essere rivistied analizzati:

• Rivedere l’implementazione di TEC, aggiungendo un modulo pereseguire e salvare query remote ed automatizzare operazioni ricor-renti da effettuare durante le operazioni di ripristino, upgrade ebackup delle base dati (moduli A e B).

• Migliorare la gestione della server farm, riducendo lo spazio occu-pato dai database dei clienti ed eliminando database residui nonpiù utilizzati (modulo C).

• Rivedere il processo di supporto interno fornito dal GSC SystemTeam al fine di migliorarne, se possibile, la produttività (modulo D).

SAP ha dato incarico al Project Manager di coordinare lo sviluppodel nuovo TEC 4.0 che andrà a sostituire la versione attualmente in uso.

La sezione seguente presenta i problemi affrontati, in coordinamentocon il Project Manager e gli altri sviluppatori. Nello specifico verrannodiscussi i seguenti moduli:

[MODULO A]

Esecuzione e salvataggio di query remote. Il problema attualmen-te evidenziato dai consulenti è l’assenza di una gestione automatizzatadelle query da eseguire. Ogni qualvolta il consulente GSC deve reperireinformazioni dalla base dati, egli deve ricorrere a Sql Server, selezionareil database su cui deve essere eseguita la query, ricordare la query daeseguire o selezionarne una da un repository, eseguirla e salvarne il risul-tato. Il risultato è tipicamente riportato a mano, copiato in un file excelo un’altra tabella temporanea.

[MODULO B]

Automazione di routine durante i processi di ripristino, upgradee backup della base dati. La versione attuale di TEC (3.0) non prevedealcun metodo per poter eseguire query preconfigurate. Ogni qual voltauno sviluppatore deve aggiungere, modificare o eliminare alcuni task, eglideve riscrivere nuovo codice o modificare il codice preesistente, toccandol’applicativo. Anche in questo caso si avverte la necessità di avere unrepository per le query da eseguire.

2. Analisi 8

[MODULO C]

Migliorare la gestione della server farm. Condurre una analisi alfine di rilevare le ragioni principali per cui TEC 3.0 fallisce, dove confallimento si intende che il Db non è stato correttamente ripristinato sullacorretta istanza e risulta quindi non accessibile da parte del consulenteGSC.

[MODULO D]

Migliorare il workflow aziendale. Analizzare il processo aziendaleinterno del GSC System Team ed evidenziare, se possibile, i workflow piùlenti proponendo ed implementando, una volta approvata, una possibilesoluzione.

2.3 Analisi dei Requisiti

In questo capitolo vengono descritti i vincoli di progetto specificati dalProject Manager, tenuti in considerazione durante la fase di progetto erealizzazione.

2.3.1 Vincoli di progetto

Le linee guida ivi specificate sono state discusse con Aurelien Leblond,Project Manager del progetto TEC 4.0

• L’ambiente di sviluppo da utilizzare deve essere Visual Studio

• Il linguaggio di programmazione deve essere C# in quanto il Teamdi sviluppo ha conoscenza pregressa con tale linguaggio

• Tutti i client girano su piattaforma Windows. Eventuali client nonNT potranno utilizzare l’applicativo tramite macchine virtuali VM-Ware [15] attualmente in fase di implementazione presso la sedecentrale di Walldorf, in Germania

• La base dati deve essere Sql Server 2005 per omogeneità con la basedati utilizzata da SAP Business One. E’ prevista una migrazionesuccessiva a Sql Server 2008.

• Data la necessità di concludere la prima release di TEC 4 entromarzo 2009 la progettazione e realizzazione dell’applicativo dovevaessere concluso entro gennaio 2009, concentrandosi sulle caratteri-stiche fondamentali del sistema invece che sul progetto di dettaglio,da effettuarsi in un secondo momento.

9 Analisi dei Requisiti

• Tutte le operazioni che comportano iterazioni con le basi dati deiclienti devono essere eseguite in un ambiente di test 3. Una vol-ta validate le funzionalità, queste possono essere implementate inTEC.

2.3.2 Casi d’uso

In figura 2.3 sono rappresentati i casi d’uso relativi ai moduli A, B, Cintrodotti nella sezione 2.2.1. Come si può vedere, vengono separate lefunzionalità riservate agli amministratori TEC (TECAdmin) dai consu-lenti (TEC User). Inoltre il TECAdmin risulta essere una specializzazionedel TEC User per cui può accedere a tutte le funzionalità di quest’ultimo(indicate dai punti 1,2,3) più altre a lui riservate (4,5,6). I casi d’usoindicati ai punti 1,5,6,8,9 sono quelli stabiliti come essenziali già nellaprima fase di realizzazione di progetto. I punti 2,3,4 sono quelli svilup-pati nell’ambiente di test, per il punto 7 è invece stata ultimata da partedi un altro sviluppatore la sezione relativa al restore.

uc Use Case Model

TEC

TECUser

1. Filter & View Result

2. Execute Query & Sav e Result

TECAdmin

6. Properties Framework

4. Backup Manager

3. Upgrade Manager

8. TEC Client

9. TEC Serv er

5. Query Admin

7. Upgrade, Backup, Restore

TEC Database

Serv er Farm

«extend»

«use»

«extend»

«extend»

«communicate»

«extend»

«extend»

«extend»

«communicate»

«use»

Figura 2.3: Use Case del Sistema

3Per l’ambiente di test si veda il progetto Visual Studio denominato RemoteQueries

2. Analisi 10

2.3.3 Planning delle attività

La fase di progettazione, descritta nel successivo Capitolo 3 inizia conlo sviluppo dei moduli A e B (in quanto il modulo B è stato inseritoall’interno del modulo A), seguito dal modulo C ed infine viene presentatala proposta di ridefinizione del sistema del modulo D.

Capitolo 3Progetto del Sistema

3.1 Moduli A e B: Generic Query

Nei paragrafi seguenti verranno descritte le fasi di progetto dei diversielementi che costituiscono i moduli A e B. In particolare verrà descrittoil canale di comunicazione tra client e server, il listener su server, la basedati, l’interfaccia PropertiesFramework, i plug-in Query Admin e QueryResult.

3.1.1 Il canale di comunicazione

Data la struttura Client Server di TEC era necessario individuare il meto-do di trasporto più opportuno per i dati che devono transitare nel canaledi comunicazione che permette il dialogo tra l’applicativo client ed il ser-ver remoto.Sono stati considerati i seguenti fattori

• Livello di trasporto da adottare

• Operazioni da svolgere in ingresso e in uscita dal canale

• Tipo di dati da fare transitare nel canale

Dato il vincolo relativo al linguaggio di programmazione e all’am-biente di sviluppo imposto dal Team Leader, la scelta è ricaduta in unaimplementazione con .NET Remoting.

Per quel che riguarda il livello di trasporto adottato, .NET Remotingsupporta i protocolli TCP, HTTP ed altri protocolli personalizzabili. Da-to che il contesto in cui opera il sistema è una VPN opportunamente con-figurata, si è scelto di implementare il sistema con Transmission ControlProtocol (TCP) e formattatore binario, fornito di default. Utilizzando

11

3. Progetto del Sistema 12

TCP invece che Hypertext Transfer Protocol (HTTP), si riduce la quan-tità di dati scambiati tra gli end-point data l’assenza degli header intro-dotti da HTTP nel payload TCP. Si è scelto di sviluppare Client e Serverin modo tale che sia comunque possibile cambiare il canale utilizzato (daTCP ad HTTP e viceversa) tramite file di configurazione.

Per i dati in transito si sono valutate le operazioni di compressione,formattazione binaria e crittografia. La formattazione binaria risulta in-dispensabile per poter trasferire i dati sul canale. La crittografia è statatrascurata in quanto tale servizio è offerto dalla VPN aziendale men-tre è stata implementata una compressione in ingresso\uscita al canale,considerata la scarsa capacità di serializzazione1 offerta da .NET.

Come evidenziato da Rammer in [17], viene suggerita l’implementa-zione di un sink di compressione qualora gli oggetti da trasferire conten-gano prevalentemente stringhe o testo. Se tale condizione è verificata sipuò arrivare ad una dimensione dell’oggetto serializzato\compresso infe-riore del 50% rispetto all’originale stream serializzato. Diverso è il casoin cui i dati da trasferire siano immagini o flussi audio\video nel qualcaso l’interfaccia di compressione deve essere implementata direttamentenel serializzatore con opportune codifiche di compressione (e.g. JPG perle immagini).

Oltre a questo, l’articolo di Schwarzkopf e Mathes [18] afferma a pa-gina 402 quanto segue: “[...] .NET seems to use a kind of UTF-8 forserialization of chars, which uses one, two or three bytes depending onthe character ”. Questa assunzione giustificherebbe l’uso di un compres-sore dato il buon livello che è possibile ottenere usando un opportunocompressore come evidenziato nell’articolo Compression of Unicode filesdi Fenwick e Brierley [12].

Nel caso in esame gli stream da trasferire contengono quasi esclusiva-mente stringhe e risultati di esecuzione, che giustificano l’implementazio-ne del sink di compressione.

In figura 3.1 vengono visualizzate le operazioni svolte dal canale eviene indicato dove dovrebbe essere inserito l’algoritmo di compressionein caso si volesse implementare in un secondo momento. Come si puònotare la compressione deve essere eseguita prima di criptare il messaggioin transito sul canale, altrimenti risulterebbe poco efficiente in termini dilivello di compressione.

Essendo .NET Remoting Object Oriented e quindi in grado di ge-stire oggetti, non sono stati specificati particolari requisiti circa il tipodi oggetti da scambiare. Saranno invece specificate alla sezione 4.1.2 lecaratteristiche di tali oggetti.

1Capacità di serializzazione intesa come dimensione in byte dello stream serializzatocompresso rispetto allo stream serializzato

13 Moduli A e B: Generic Query

CLIENT

CHANNEL

SERVER

CHANNELOBJs

Serializable Objects- Query- Result- Event

- Db Type

CHANNEL

COMPRESSION ENC.

OBJs

CHANNEL

COMPRESSIONENC.BINARY FORM. BINARY FORM.

pwdf6541TEC User

SAP VPN

TEC User

Figura 3.1: Channel

3.1.2 Il Server Listener

Scopo del Server Listener è quello di offrire servizi ai clients, gestendo leinformazioni in input ed in output con la base dati.

SERVER

CHANNEL

TEC DBLISTENER

Figura 3.2: Listener

Per poter dialogare con la base dati le possibilità erano o fornire unaccesso autonomo indipendente per ognuno dei servizi implementati dalListener oppure implementare un framework di comunicazione tra i serviziimplementati sul listener e la base dati.

La possibilità di poter usufruire di un accesso indipendente servizioper servizio permette allo sviluppatore di decidere in piena autonomiacome gestire le comunicazioni con la base dati, come ad esempio il timeoutdi connessione, la gestione delle transazioni, la modalità di accesso alletabelle. Questa autonomia si può comunque rilevare controproducente inquanto:


• Lo sviluppatore potrebbe non avere conoscenza relativa alla strut-tura dell’intera base dati

• Lo sviluppatore potrebbe focalizzarsi sulla sue operazioni senza va-lutare le eventuali implicazioni che questo può avere su operazioniconcorrenti svolte da altri sviluppatori

• Si rischia di introdurre ridondanza nel caso in cui uno sviluppatorenecessiti delle informazioni fornite da una certa vista, e non siaal corrente che tale funzionalità è già implementata in un serviziosviluppato da un altro programmatore

La seconda possibilità è invece l’utilizzo di un framework per l’accessoalla base dati: il framework conterrà un insieme predefinito di funziona-lità e nel caso in cui una funzionalità richiesta non sia presente, essadovrà essere notificata allo sviluppatore del framework. Sarà compito diquest’ultimo fornire il metodo di accesso nel modo più opportuno.

Questa soluzione toglie definitivamente allo sviluppatore del serviziola possibilità di accesso diretto alla base dati, dall’altro però garantiscela consistenza della base dati ed in caso di malfunzionamento o modifichesarà necessario intervenire unicamente sul framework invece di metteremano a tutti i servizi implementati dai diversi sviluppatori.

Si noti in figura 3.3 dove si è deciso di implementare l’interfacciaPropertiesFramework per l’accesso alla base dati.

SERVER

CHANNEL

TEC DBLISTENER FRAMEWORK

Figura 3.3: Properties Framework

3.1.3 La Base Dati

L’accesso alla base dati poteva essere implementato in 2 differenti modi. Idue modi di accesso verranno qui esposti e verrà data una giustificazionedella scelta effettuata.

Accesso con query definite nel codice

In questo caso lo script della query da eseguire è nidificato all’interno delcodice C# dell’interfaccia PropertiesFramework. Quando il programma-tore richiama una funzionalità in PropertiesFramework, l’implementazio-


ne dell’interfaccia stabilisce una connessione con la base dati ed inoltral’intera stringa contenente la query da eseguire.

Accesso con Stored Procedures

In questo caso nell’implementazione di PropertiesFramework viene speci-ficato solamente il nome della stored procedure esistente all’interno dellabase dati, che deve essere richiamata. Quando il programma richiamauna funzionalità in PropertiesFramework, l’implementazione stabilisceuna connessione con la base dati e richiama la Stored Procedure.

Durante la fase implementativa è stato scelto questo secondo approc-cio a seguito delle seguenti considerazioni:

• Modularità offerta dalle stored procedures: in caso di bug o modifi-che da eseguire sulla query in oggetto (o piu generalmente parlandodel batch da eseguire) risulta indubbiamente più semplice effettuareil debug della stored procedure su Sql Server piuttosto che analizza-re una stringa immersa nel codice C#. Oltretutto la nuova versionedi Sql Server 2008 offre un ambiente di debug contenente molte dellefunzionalità di debug presenti in Visual Studio. Data la retrocom-patibilità con basi dati Sql2005 offerta da Sql Server 2008, è orapossibile utilizzare l’ambiente di debug offerto da quest’ultimo perl’analisi e il debug delle stored procedures. stesse.

• è possibile effettuare il tuning delle stored procedures, utilizzan-do l’Execution Plan ed il Tuning Advisor integrati in Sql Server.Tramite questi programmi una stored procedure può essere rivistaed eventualmente modificata per diminuirne il tempo di esecuzio-ne (quando possibile). Tale operazione è del tutto trasparente al-l’interfaccia Properties Framework che quindi non richiede d’esseremodificata.

• Per quanto detto a inizio paragrafo, il traffico di rete viene ridot-to in quanto non è necessario passare a Sql Server l’intera stringacontenente la query ma solamente il nome della stored procedure.

• Maggiore interoperabilità: nel caso in cui insorga la necessità disviluppare applicativi in linguaggi differenti, basterà che questi ab-biano una interfaccia di accesso ai dati per Sql Server, per poterrichiamare le stored procedure preesistenti

• Il codice definito all’interno delle stored procedures viene analizzatodal parser di Sql Server e dopo la prima esecuzione verrà genera-ta una versione in-memory che verrà eseguita più velocemente airichiami successivi.


A fronte di questa discussione si devono tuttavia ricordare alcuni ca-si in cui l’implementazione di stored procedures all’interno del codicepossono offrire una valida alternativa, ossia quando:

• La query da eseguire viene generata a runtime

• I dati di ritorno di una stored procedure sono usati per creare unanuova stringa T-SQL.

Lo schema finale che ne deriva è quello mostrato in figura 3.4

SERVER

CHANNEL

TEC DB

FRAMEWORKVIEW

LIBRARYSTORED PROCEDURE

LIBRARY

TABLE

Figura 3.4: Modello di Accesso ai dati

Viste

Si è deciso di interfacciare le stored procedures con delle viste piuttostoche interfacciarle direttamente con le tabelle. Questa decisione è statapresa a seguito delle seguenti considerazioni:

• La vista consente di visualizzare tabelle e relazioni tra tabelle in unformato più conveniente

• Il tempo di accesso ai dati su una vista è esattamente lo stesso diaccesso diretto alle tabelle da cui la vista è stata ottenuta.

• Possono essere combinate con ruoli (che rappresentano diversi grup-pi di utenti) per consentire l’accesso esclusivo a tabelle e\o viste aseconda del ruolo assegnato all’utente.

• In caso di modifica alla tabella di origine, la vista può essere mo-dificata in modo tale da offrire la medesima interfaccia alle querye\o stored procedure che la utilizzano.

Lo svantaggio principale derivante dall’uso delle vista sta nel fatto che,in caso di modifica ad una determinata tabella, referenziata da viste


multiple, potrebbe essere necessario modificarle tutte per garantire ilfunzionamento delle stored procedures.

Nel caso in oggetto, date le molteplici stored procedure che si andran-no a sviluppare si è scelto di ricorrere all’uso delle viste

Schema

Un’altro concetto offerto da Sql Server che si è deciso di utilizzare è statoil concetto di schema.

Scopo dello schema è quello di separare gli oggetti sul database daidiritti utente. Lo schema può essere visto come una unità logica che rac-coglie più oggetti. Esso può essere utilizzato per diversi scopi [[6]] ma nelnostro caso si è scelto, in comune accordo con gli altri DBA di utilizzaregli schema per separare le varie aree del database.

Le aree proposte sono state:

• B1

• BackupManager

• Core

• Infrastructure

• Internal

• Properties

• Security

come evidenziato in figura 3.5.Per quanto sviluppato in questa Tesi, tabelle, viste, stored proce-

dures saranno tutte identificate dallo schema Properties e dallo schemaBackupManager.

Ridefinizione dei requisiti

I requisiti inerenti la base dati e riportati in Appendice A sono statireinterpretati e riassunti nelle tabelle 3.1, 3.2, 3.4 e 3.3. Entity e Eventsono qui omessi per non appesantire la trattazione.

Il Modello E-R che ne deriva è mostrato in figura 3.6


QUERYHA una descrizionePUO’ riferire ad una SAP notePUO’ essere pubblicaHA il testo della queryPUO’ avere un ordine di esecuzioneHA una data di modificaHA uno timestamp di modificaE’ ASSOCIATA ad un eventoE’ inserita da un TECAdminPUO’ produrre dei risultatiPUO’ essere eseguita su un solo specifico tipo di database

Tabella 3.1: Tabella Query

RESULTHA un risultato di esecuzioneE’ ASSOCIATO ad una queryE’ PRODOTTO da un utenteAPPARTIENE ad un ticketHA una data di modificaHA un timestamp di modificaPUO’ essere un risultato d’errore

Tabella 3.2: Tabella Result

BATCHHA un ID di esecuzioneHA uno StatoPUO’ generare nessuno, uno o più risultati

Tabella 3.3: Tabella Batch


class Db Schemas

Db Schemas

B1

Core

Infrastructure

Internal

Properties

Security

BackupManager

Figura 3.5: Schema definiti nel database TEC

3.1.4 L’interfaccia Properties Framework

In figura 3.7 sono rappresentati i servizi offerti dall’interfaccia Propertie-sFramework e le relazioni con le stored procedure della base dati. I serviziofferti sono di 3 tipi: Salvataggio, Esecuzione e Selezione. Le operazio-ni di modifica ed eliminazione non sono state prese in considerazione inquanto il Project Manager ha proposto di creare un Framework comu-ne a tutti gli schema per le operazioni di UPDATE, DELETE. Inoltre,data la disponibilità di un DBA, non ha senso provvedere allo sviluppodi operazioni INSERT, UPDATE e DELETE per entità quali ENTITYed EVENT. ENTITY ed EVENT infatti sono raramente modificati, RE-SULT è sempre aggiunto automaticamente e non ha senso una modificadel risultato di una query. L’operazione di DELETE non deve essereeffettuata da parte degli sviluppatori ma eseguita automaticamente nelcaso un messaggio CSN venga chiuso o il database sia stato eliminato (siveda la parte di implementazione per le riflessioni in merito).


RELAZIONIQUERY può generare zero o più RISULTATIRISULTATO può essere generato da una e una sola QUERYQUERY è inserita da uno ed un solo TECADMINTECADMIN può inserire zero o più QUERYQUERY può essere eseguita su una ed una sola ENTITàENTITA’ può essere oggetto di zero o più QUERYQUERY può generare un RISULTATO di erroreRISULTATO è output di una ESECUZIONETECUSER può eseguire una o più ESECUZIONIRISULTATO può appartenere a un BATCH di esecuzioneUn BATCH di esecuzione può generare uno o più risultatiUna QUERY può eseguire come BATCH

Tabella 3.4: Tabella Relazioni

Properties.Query GENERATE Properties.Reult

Security.TECUser

ADD

ON

Properties.Entity

EXECUTE

ResultID

ResultDateExecutionResult

1,1

0,N

1,10,N

0,N

1,1

QueryDescriptionSAPNoteIsPublic

QueryText

QueryID

0,N 1,1

EntityID

TECUserIDCore.Ticket

Description

RETRIEVE

RAISE

Properties.Event

EventIDDescription

0,N

0,1

TicketID

1,1

0,N

Properties.Batch BELONG

BREED

OWN Properties.Status

0,N

1,1

0,1

0,N

1,10,N StatusID

Description

BatchID

Figura 3.6: Modello E-R Schema Properties


WH

AT

TO

DO

EX

EC

UT

E A

Q

UE

RY

ALR

EA

DY

S

TO

RE

D O

N

DB

CH

EC

K

BE

FO

RE

S

AV

INGY

Get

Sav

edQ

uery

Res

ult

Y

TIM

E

CO

NS

UM

ING

Q

UE

RY

Exe

cute

And

Sav

eR

esul

tE

xecu

teA

ndS

ave

Res

ultA

sync

NG

etR

emot

eQue

ryR

esul

t

N

EX

EC

Lin

e

SA

VE

A Q

UE

RY

Sav

eQue

ry

SA

VE

A R

ES

ULT

Sav

eRes

ult

SA

VE

Lin

e

GE

T L

IST

OF

Q

UE

RY

GE

T L

IST

OF

R

ES

ULT

GE

T L

IST

OF

E

NT

ITIE

SG

ET

LIS

T O

F

EV

EN

TS

Get

Que

ryLi

stG

etQ

uery

Res

ult

List

Get

Ent

ityLi

stG

etE

vent

List

NY

GE

T A

SP

EC

IFIC

R

ES

ULT

Get

Sav

edR

esul

t

6

3

7

1

811

54

2

910

GE

T L

IST

OF

B

AT

CH

GE

T L

ine

Get

Bat

chLi

st

12

1 2 3 4 5 6

Set

Res

ult

Set

Que

ry

Get

Sav

edQ

uery

Res

ult

Get

Sav

edQ

uery

Res

ult,

Set

Res

ult

Get

Sav

edQ

uery

Res

ult,

Set

Res

ult

Get

Rem

oteQ

uery

Res

ult

7 8 9 10 11 12

Get

Que

ryLi

st

Get

Que

ryR

esul

tLis

t

Get

Ent

ityLi

st

Get

Eve

ntLi

st

Get

Res

ult

Get

Bat

ch

ST

OR

ED

PR

OC

ED

UR

ES

ST

OR

ED

PR

OC

ED

UR

ES

IPro

pert

iesF

ram

ewor

k

Figura

3.7:

ServiziO

ffertid

aPrope

rtiesFram

ework


3.2 Modulo C: Backup Manager

Riprendendo quanto esposto nella sezione 2.2.1, lo scopo del modulo diBackup Manager è quello di identificare il problema che porta la proce-dura di restore a fallire, compromettendo il funzionamento dell’ambienteTEC. L’ambiente TEC è composto di 15 servers, locati in Germania sulquale sono installate 75 istanze tra Sql2000, Sql2005 (La lista completadelle istanze è riportata in appendice).

L’impossibilità di ripristinare i database dipendeva dai seguenti mal-funzionamenti:

• userID e\o password dell’area Secure File Transfer Protocol (SFTP)non corretti

• backup non compresso e\o compresso in formato differente dai for-mati supportati (.zip e .rar)

• file compresso corrotto

• mismatch tra la versione del backup (e.g. Sql2005) e il server su cuieseguire il restore (e.g. Sql2000)

• versione di Business One non conforme alla versione dichiarata infase di richiesta del TEC Ticket, con conseguente mismatch tra ilCOMPANY-DB e l’SBO-COMMON

• fallimento della procedura di unzip a causa di mancanza di spaziosu server

• fallimento della procedura di restore a causa di mancanza di spaziosu server

• impossibilità di operare sulla base dati a causa della impossibilitàdi allocare spazio su server

Per poter identificare quali di questi problemi erano i più significativisono stati analizzati i messaggi IT inseriti in CSN dai consulenti SAP perrisolvere le problematiche incontrate durante l’utilizzo di TEC.

I consulenti hanno richiesto nell’arco di tre anni 3897 richieste di in-tervento da parte di un TECAdmin. Di tutti i TECAdmin (21 in totale)sono stati individuati quelli con il maggior numero di messaggi analiz-zati (8 TECAdmin) che da soli hanno provveduto a risolvere l’80% deimessaggi totali. Questi consulenti sono stati contattati per avere un lorofeedback circa le cause di malfunzionamento. Oltre ai feedback dei con-sulenti sono stati analizzati 20 messaggi scelti a campione per ognuno deiconsulenti individuati, per un totale di 160 messaggi analizzati.

23 Modulo C: Backup Manager

La verifica incrociata tra i feedback e i messaggi campione analiz-zati ha portato all’individuazione della causa principale per cui l’ope-razione di restore dei database falliva ossia la mancanza di spazio suserver. Tale situazione è stata rilevata eseguendo un analisi dei Db (siveda lo script Analysis.sql e la tabella [snapshot].[RequiredDatabase] neldatabase TEC).

Come si vede dal trend del grafico sottostante, il numero di databaseripristinati sui server è andato via via aumentando, mese dopo mese. Idatabase vengono eliminate automaticamente quando non utilizzati perpiù di 14 giorni, questo giustifica l’andamento discendente in alcuni punti.

Figura 3.8: Numero database ripristinati su server

Il secondo grafico mostra invece il totale annuo di database ripristinatisu server. Si noti che per l’anno 2006 e 2009 i dati sono stati previsti datoche nel 2006 l’uso di TEC è iniziato a dicembre e nel 2009 I dati sonostati raccolti a metà febbraio.

Figura 3.9: Totale spazio annualmente allocato sui server

Le previsioni per il 2009 sono ottimistiche e non tengono conto di


possibili flessi dovuti alle minori richieste di supporto data l’attuale si-tuazione economica a livello mondiale.

Sulla base di tali considerazioni è quindi necessario ottimizzare l’u-tilizzo delle risorse a disposizione invece di fare investimenti economicipuntando sull’acquisto di hardware dedicato (sempre che questo vengaautorizzato dalla dirigenza).

3.2.1 La Procedura di Restore attuale

Quando il consulente necessita di ripristinare un database compila il formdi figura 3.10, immettendo il message number del messaggio CSN, il cu-stomer number, la versione di Business One, il tipo di Server e i parametridi accesso all’area SFTP. L’applicativo determina, in base ad una logi-ca interna 2 il server sul quale deve essere fatto il download del databasecompresso in formato .zip o .rar . Verrà quindi create una cartella nel net-work path \ \ServerName \backups$\Data ed ivi verrà creata una cartel-la nel formato Anno_CSNMessageNr_CSNCustomerNr_TECTicketNr.In questa cartella verrà riposto il database, esso verrà estratto nella sot-tocartella tmpTEC, ripristinato su server con nomeAnno_CSNMessageNr_CSNCustomerNr_TECTicketNr e la cartella tmp-TEC verrà immediatamente eliminata. Dopo 14 giorni di inutilizzo deldatabase sia la cartella che il database con nomeAnno_CSNMessageNr_CSNCustomerNr_TECTicketNr verranno elimi-nati 3.

3.2.2 Problemi Rilevati

A seguito delle interviste condotte con gli sviluppatori del modulo TECpreposto all’operazione citata nel paragrafo precedente, le possibili causedi spreco di spazio sono:

• creazione da parte dei TECAdmin di cartelle che non corrispondonoa nessun database a seguito di restore manuale.

• estrazione manuale e dimenticanza del file scompattato .bak nelladirectory tmpTEC

• ripristino di database sui server senza seguire le regole di nomen-clatura sopracitata

2Per determinare l’istanza corretta viene comparata la versione, la patch level e iltipo di database dichiarato dal consulente al momento della richiesta del messaggio.Una volta determinata l’istanza corretta, viene scelto tra tutti i server con l’istanzarichiesta, quello con spazio maggiormente libero.

3La procedura di restore per òa versione TEC 4.0 ripristina il databasecon nome TECTicketNr per il COMPANY-DB e TECTicketNr_COM___ perl’SBO-COMMON.

25 Modulo C: Backup Manager

Figura 3.10: TEC 3 - GUI Richiesta ticket


• mismatch tra la nomenclatura della cartella e il database ripristi-nato.

I database, una volta ripristinati vengono o utilizzati dai consulenti o neviene fatto un upgrade: Tutte le transizioni eseguite nel database vengonosalvate nel Transaction Log. Il Transaction Log risulta essenziale in casodi rollback ad una situazione precedente ma risulta controproducentenel caso in analisi in quanto va ad aumentare drasticamente lo spaziooccupato dal database, specie a seguito di una operazione di upgrade.Per una trattazione più esauriente si rimanda a [5].

3.2.3 Possibili Soluzioni

I problemi rilevati possono essere risolti con le seguenti operazioni:

• eliminazione delle cartelle su server non conformi al formatoAnno_CSNMessageNr_CSNCustomerNr_TECTicketNr

• eliminazione dei database non conformi al formatoAnno_CSNMessageNr_CSNCustomerNr_TECTicketNr

• shrink di tutti i database presenti su server

Prima di poter procedure con tale implementazione deve essere valu-tato se vale la pena sviluppare un software appositamente per tali attivitào se piuttosto conviene pulire manualmente i server. Il tempo necessarioalla verifica deve essere limitato rispetto al tempo necessario a svilupparel’eventuale software.

Si è deciso di utilizzare il software SequoiaView [19], sviluppato dal-l’Università Tecnica di Eindhoven per verificare lo stato dei server.

è stato creato uno ColorScheme (si veda il file SequoiaTecColors.txt)con la mappa colori. Un tipico screenshot è rappresentato in figura 3.11

Come si può notare la situazione è critica in quanto file di backup(rosso) occupano una grossa percentuale dello spazio su hard disk. Ana-logamente alcuni database hanno file .mdf (blu) e file .ldf (viola) piuttostoestesi a causa della mancata operazione di shrink.

Per quanto detto si è deciso di sviluppare:

• un applicativo per la rilevazione delle cartelle con mismatch

• uno script per eseguire lo shrink distribuito sui server, da imple-mentare come Job su Sql Server

In figura 3.12 è riportato lo schema di funzionamento dell’applicativoBackupManager, la cui implementazione è descritta nel capitolo 4.

27 Modulo D: Ridefinizione GSC Workflow

Figura 3.11: Snapshot Sequoia

3.2.4 Schema E-R Backup Manager

Il modello E-R relativo allo schema BackupManager è rappresentato infigura 3.13.

In questo caso la struttura della base dati è piuttosto semplice inquanto sono immediatamente distinguibili tre entità: Server, Directory eFile. Un server può contenere più directory ed una directory può conte-nere più file. Analizzando in senso opposto si ha invece che un file puòessere contenuto in una ed una sola directory ed una directory può esserecontenuta in uno ed un solo server. Come si vede dal modello-ER vengonoomesse tutte le informazioni non pertinenti (come ad esempio eventualisottocartelle), questo perché lo scopo è quello di identificare cartelle conpiù di un file (che dovrebbe essere il file compresso contenente il backupdel database) e cartelle orfane (ossia non associate a nessun ticket).

3.3 Modulo D: Ridefinizione GSC Workflow

Lo schema rappresentato in figura 3.14 riassume il workflow attualmentein uso.

Quando un consulente (FI, LOG, AP\AR...) analizza un messaggiopuò essere necessario richiedere un upgrade. In tal caso la richiesta vieneelaborata dall’ambiente TEC e quindi eseguita. Una volta ultimato ilprocesso di upgrade il consulente viene notificato sull’esito positivo o me-no dell’upgrade. In caso l’esito sia negativo, il consulente deve contattareun membro del System Team e notificare il fallimento dell’upgrade.


Pwdf2660

BackendRootList

BackendServer

Directory

File

GetBackendRootList

ServerManagerServerManagerSetServer

SetDirectory

SetFile

RestoredDatabase

BackupManager SCHEMA

COLLECT DATA

STORE DATA

TEC_LIVE

DistributedShrink_V2.sql(STEP 4)

1.

1. Executed when the application starts2. Executed when the button “COLLECT DATA” is pressed3. Executed when the button “STORE DATA” is pressed4. Executed on Step 4 in DistributedShrink_V2.sql

3.

4.

ServerManager()

2.

Figura 3.12: Overview Backup Manager

Il System Consultant a questo punto analizza il database di partenzaper determinare la causa che ha impedito l’upgrade, determina quindi ilfix da applicare e reinoltra la richiesta di upgrade. A questo punto egliotterrà l’esito dell’upgrade. Se positivo, potrà notificare a sua volta l’esitoal consulente GSC che ha inoltrato la richiesta, altrimenti deve reiterare ilprocesso di analisi\fix fino a quando la procedura non va a buon fine. Unavolta che il consulente riceve notifica di avvenuto upgrade, può continuarecon la sua attività di analisi sul database in oggetto e portare a terminel’attività di message processing.

Si noti che l’attività del General Consultant è non bloccante in quan-to nel momento in cui l’attività di restore solving viene delegata ad unmembro del System Team, egli può proseguire con l’analisi di un nuovomessaggio. L’attività del System Consultant è invece bloccante in quan-to egli tiene in carico il database sintantoche la procedura di upgradecontinua a fallire. Le attività più dispendiose sono appunto quelle dianalisi e problem solving. Oltretutto allo stato attuale vi sono solamen-te un paio di note SAP atte a rilevare possibili cause di upgrade failure(questo comporta che il System Consultant debba comunque interveniremanualmente per applicare il fix).

L’idea di sviluppo è quella di automatizzare, per quanto possibile,le attività di failure analysis e problem solving, spostandole all’internodell’ambiente TEC in modo tale da utilizzare il meno possibile i consu-lenti per la risoluzione di problemi interni. La soluzione proposta è quel-


DirectoryIDName

0,N

DIRECTORY

FILE

BACKEND SERVER

TO HOLD

TO HOLD

1,1

0,N

1,1

CreationTimeLastAccessTime

NumFiles

BackendIDServernameBackupRoot

FileIDNameType

Figura 3.13: Modello E-R Schema BackupManager

la di utilizzare la struttura messa a disposizione dalle query generichesviluppate nel MODULO A.

L’idea di ridefinizione del workflow è illustrata in figura 3.15. In que-sto nuovo schema è stato aggiunto il processo denominato Forced Upgradeallo scopo di modificare il database rendendolo compatibile con la pro-cedura di upgrade. Tale processo si trova all’interno dell’ambiente TECe non richiede quindi alcun dispendio di tempo da parte dei consulenti.Solo nel caso in cui tale procedura fallisca, il database sarà analizzato daun System Consultant. Lo scopo è quello di potenziare il più possibiletale processo, riducendo gli interventi del System Team. Per fare questoogni qual volta una procedura di upgrade fallisce, il System Consultantvaluta se questo è dovuto ad un problema specifico della base dati delcliente (ad esempio una User Defined Table (UDT) aggiunta o un UserDefined Field (UDF) settato in modo non conforme alle specifiche SAP)o è un problema generale (tipicamente modifiche alle tabelle di sistemaSAP: modifica lunghezza campi nelle System Table). In questo secondocaso la procedura potrebbe essere automatizzata. L’effettiva implementa-zione viene valutata dall’Upgrade Solution Desk (USD) (attore aggiuntoche deve essere definito) tramite il processo di Issue Knowledge Transfer.I dettagli relativi alle procedure sono riportati nella sezione 4.3.


act Workflow

GENERAL CONSULTANT TEC ENVIRONMENTSYSTEM CONSULTANT

UPGRADE

End MessageProcessing

CONSULTING

MessageProcessing

Upg?

UPG. NOTIFICATION

Failure?UPG. FAILURE

ANALYSIS

PROBLEM SOLVING

UPG. NOTIFICATION

Upg?

POST FIX UPGRADE

UPG. NOTIFICATION

PICK A NEW MESSAGE

MESSAGE SOLVING

GO TO Consulting

GO TO Pick a new message

Y

Y

N

Y

N

Figura 3.14: Workflow Attuale


act Workflow

UPG. SOLUTION DESKTEC ENVIRONMENTSYSTEM CONSULTANTGENERAL CONSULTANT

UPGRADE

End MessageProcessing

CONSULTING

MessageProcessing

Upg?

UPG. NOTIFICATION

Failure?

UPG. FAILURE ANALYSIS

PROBLEM SOLVING

UPG. NOTIFICATION

Upg?

POST FIX UPGRADE

UPG. NOTIFICATION

MESSAGE SOLVING

PICK A NEW MESSAGE

FORCED UPGRADE

UPGRADE NOTIFICATION

Failure?

GO TO Message Solving

Recurrent?

UPG. ISSUEKNOWLEDGE

TRANSFER

GO TO Pick a new msg

GO TO Pick a new message

Y

Y

N

N

N

N

Y

Y

Y

Figura 3.15: Workflow Ridefinito

Capitolo 4Implementazione

4.1 Moduli A e B

4.1.1 Properties Framework

L’interfaccia IPropertiesFramework e la sua implementazione è mostratain figura 4.1.

I parametri in input ai metodi sono tutti di tipo primitivo, per omo-geneità con la base dati cui i parametri verranno passati. I risultati inoutput sono tipi primitivi, DataSet e DataTable. Per poter essere utiliz-zati in modo opportuno, il programmatore deve essere a conoscenza dellastruttura dei DataSet e dei DataTable tornati dall’interfaccia.

In particolare i DataSet sono sempre tornati in seguito all’esecuzionedi una query, i DataTable sono invece tornati ogni qual volta vengonoacquisiti dati (siano essi relativi a Query, Result, Batch, ...) dalla basedati.

Particolare attenzione è stata posta nel metodo ExecuteAndSaveRe-sultAsync. Questo metodo riceve come parametri di ingresso il QueryIDdella query da eseguire, il ticketID sul quale la query deve essere eseguitae il TECUSerID dell’utente che sta effettuando l’operazione. Tale metododeve eseguire in modalità asincrona per non bloccare l’applicativo client.

Le possibilità analizzate sono state l’uso di un pool di thread e i threadmultipli.

In particolare sono state evidenziate le seguenti informazioni:

• Non ci sono priorità differenti tra thread diversi

• Il thread può eseguire per un tempo relativamente lungo ma l’ela-borazione vera e propria (l’esecuzione della query) viene eseguita inun server diverso da quello dove il thread viene creato ovverosia nelserver dove è fisicamente allocato il database target della query.

33

4. Implementazione 34

• Non è richiesto che i thread siano identificabili. Un thread vieneeseguito e muore senza notificare la fine dell’elaborazione al clientchiamante.

• Deve essere eventualmente possibile impostare il numero massimodi thread in esecuzione, dato che le risorse sui server non devonosolamente essere dedicate all’esecuzione di query.

La classe che meglio rappresenta questa situazione è la classe Thread-Pool che utilizza un pool di thread [11]. Il ThreadPool non è stato usatodirettamente, ma tramite l’uso dei delegati, come mostrato nel frammentodi codice qui riportato:

1 // delegate for method ExecuteAndSaveResult2 public delegate bool DelegExecuteAndSaveResult(int?

queryID, int? ticketID, int? TECUserID, int? batchID);3

4 // Delegate of type5 DelegExecuteAndSaveResult delegateExecuteAndSaveResult;6

7 [...]8

9 public int ExecuteAndSaveResultAsync(int? queryID, int?ticketID, int? TECUserID)

10 {11 int batchID = GetBatch(queryID, ticketID);12 delegateExecuteAndSaveResult =

ExecuteAndSaveResult;13 delegateExecuteAndSaveResult.BeginInvoke(

queryID, ticketID, TECUserID, batchID,null, null);

14 return batchID;15 }

Viene creato un delegato con la stessa firma (parametri e valori diritorno) del metodo che esegue in modalità sincrona. Il metodo asincro-no acquisisce dalla base dati l’ID del batch che deve essere eseguito. Ildelegato viene inizializzato e viene eseguito il metodo BeginInvoke che fapartire l’esecuzione asincrona del metodo ExecuteAndSaveResult. Il bat-chID identificante la query in esecuzione viene immediatamente tornatoal chiamante.

4.1.2 Gli oggetti serializzabili

Una volta stabilite le funzionalità che l’interfaccia PropertiesFrameworkè in grado di offrire (Sez. 3.1.4), si devono definire quali oggetti devonoessere creati e trasferiti (mediante serializzazione) al client remoto.

35 Moduli A e B

class Class Model

PropertiesFrameworkImpl

- delegateExecuteAndSaveResult: DelegateExecuteAndSaveResult

+ DelegateExecuteAndSaveResult(int?, int?, int?, int?) : bool+ ExecuteAndSaveResult(int?, int?, int?, int?) : bool+ ExecuteAndSaveResultAsync(int?, int?, int?) : int- GetBatch() : int+ GetEntityList() : DataTable+ GetEventList() : DataTable+ GetQueryList(bool) : DataTable+ GetQueryResultList(int?) : DataTable+ GetRemoteQueryResult(int?, string, int?) : DataSet+ GetSavedQueryResult(int?, int?) : DataSet+ GetSavedResult(int?) : DataTable- SaveErrorResult(int?, int?, int?, string, int?) : bool+ SaveQuery(string, int?, int?, string, bool?, int?, int?, int?) : int+ SaveResult(int?, int?, int?, DataSet, int?) : bool

«interface»

IPropertiesFramework

+ ExecuteAndSaveResult(int?, int?, int?, int?) : bool+ ExecuteAndSaveResultAsync(int?, int?, int?) : int+ GetEntityList() : DataTable+ GetEventList() : DataTable+ GetQueryList(bool) : DataTable+ GetQueryResultList(int?) : DataTable+ GetRemoteQueryResult(int?, string, int?) : DataSet+ GetSavedQueryResult(int?, int?) : DataSet+ GetSavedResult(int?) : DataTable+ SaveQuery(string, int?, int?, string, bool?, int?, int?, int?) : int+ SaveResult(int?, int?, int?, DataSet, int?) : bool

Figura 4.1: Interfaccia PropertiesFramework e sua implementazione

In tal caso si può fare riferimento alla struttura database creata, chefornisce utili informazioni circa la struttura degli oggetti:

• un Risultato è sempre associato ad una Query

• Una Query ha sempre associata una Entity ed un Evento

Quindi una valida rappresentazione è fornita da un oggetto Risultatoche contiene un oggetto Query. A sua volta l’oggetto Query contienel’oggetto Entity e l’oggetto Evento.

Analogamente si potrebbe definire che Entity contiene una lista dioggetti Query, Event contiene una lista di oggetti Query e Query con-tiene una lista di Results. Non si deve però dimenticare che tali oggettidevono essere scambiati all’interno di una rete WAN e la lista può poten-zialmente contenere una elevata quantità di dati. Questo influenzerebbenegativamente il server ove è in esecuzione il listener, a causa della mag-gior computazione necessaria per generare gli oggetti summenzionati e larete, per il maggior traffico dati generato. Ricordiamo inoltre, che quan-do si opera in una WAN una delle problematiche più importanti di cuisi deve tener conto è la latenza. In questo caso l’obiettivo è quello diridurre le chiamate cross-network trasferendo la maggior quantità di datipossibili ma necessari, in un singolo network round trip.


Il mancato uso delle liste negli oggetti costringe l’applicativo client adover gestire le relazioni tra gli oggetti. Per offrire un maggior supporto atali operazioni si è deciso di implementare due ulteriori metodi all’internodell’oggetto Result. Tali metodi sono List<Result> GetAll(Ticket ticket)e List<Result> GetAll(Query query, Ticket ticket).

Il primo metodo consente di reperire da server la lista di risultati diun particolare ticket, il secondo metodo invece ritorna la lista di risultatidi un particolare ticket associati all’esecuzione di una specifica query. Danotare che l’implementazione di tali metodi non deve caricare il datatablerelativo ad ogni risultato. Il datatable verrà tornato al client solamentea seguito dell’esecuzione del metodo ExecutionResult.

Il diagramma delle classi che ne deriva, per le considerazioni fatte, èriportato in figura 4.2.

4.1.3 Server Listener

In questo paragrafo verrà descritto come si è scelto di implementare ilServerListener su server.

.NET Remoting infatti offre diverse possibilità di attivazione deglioggetti remoti:

• Server Activated Object (SAO)

• Client Activated Object (CAO)

SAO: prima che un metodo remoto sia invocato su un oggetto remoto,l’oggetto deve esistere o essere creato. SAObjects vengono creati quantoil client invoca la prima chiamata a metodo remoto.

SAO a sua volta ha due metodi di registrazione: Singleton e Single-Call. Singleton viene istanziato una sola volta e serve tutte le chiamateda parte dei clients in maniera multithread. Oggetti Singlecall vengonoinvece creati ogni qual volta un metodo remoto viene invocato in questotipo di oggetti. L’oggetto singlecall ha un tempo di vita assai limitato inquanto vive per il tempo necessario a processare la chiamata del client esono quindi adatti per istanziare oggetti che non necessitano di uno stato.

CAO: Sono creati sul server immediatamente alla richiesta del client.Un’istanza di un oggetto CAO è creata ogni qual volta un client ne istan-zia una ed il tempo di vita è controllato dal client. La logica dei metodiCAO viene gestita nel proxy del client.

Le informazioni riportate sono le minime essenziali per comprenderela scelta di implementazione. Per una descrizione più esaustiva si rimandaa [17]

37 Moduli A e B

class SerializableObjects

IEquatable

Entity

- e_description: string- e_ID: int

+ Add(Entity) : Entity+ Delete(Entity) : void+ Entity(int, string)+ Equals(Entity) : bool+ GetAll() : List<Entity>+ ToString() : string+ Update(Entity) : Entity

«property»+ Description() : string+ ID() : int

IEquatable

Ev ent

- e_ID: int- e_name: string

+ Add() : Event+ Delete() : void+ Equals(Event) : bool+ Event(int, string)+ GetAl l() : List<Event>+ ToString() : string+ Update() : Event

«property»+ EventID() : int?+ Name() : string

IEquatable

Query

- q_Entity: Entity- q_Event: Event- q_ID: int?- q_IsPublic: bool- q_Order: int?- q_SAPNote: int?- q_TECUserID: int?- q_Text: string- q_timestampChg: byte ([])- q_Title: string

+ Add() : Query+ Delete() : void+ Equals(Query) : bool+ Get(string) : Query+ GetAll() : List<Query>+ GetAll(Event) : List<Query>+ GetByKey(int?) : Query+ Query(int, string, int?, bool, int?, string, int?, byte[], Event, Entity)+ Query(string, int?, bool, int?, string, int?, Event, Enti ty)+ ToString() : string+ Update() : Query

«property»+ Entity() : Entity+ Event() : Event+ ID() : int?+ IsPublic() : bool+ Order() : int?+ SAPNote() : int?+ TECUserID() : int?+ Text() : string+ TimeStamp() : byte[]+ Title() : string

IEquatable

Result

- r_batchID: int- r_dateTime: DateTime- r_executionResult: DataTable- r_ID: int- r_query: Query- r_TECUserID: int- r_timeStamp: byte ([])

+ Equals(Result) : bool+ ExecuteAndSaveResult(Query, Ticket) : void+ ExecuteAndSaveResultAsync(Query, Ticket) : void+ GetAll(Ticket) : List<Result>+ GetAll(Query, Ticket) : List<Result>+ GetByKey(int) : Result+ GetQueryResultList(Ticket) : DataTable+ GetResult(Query, Ticket) : DataSet+ GetSavedQueryResult(Query, Ticket) : DataSet+ Result(int, Query, int, byte[], DateTime, int)+ Result(int, Query, int, byte[], DateTime, DataTable)+ ToString() : string

«property»+ BatchID() : int+ DateTime() : DateTime+ ExecutionResult() : DataTable+ ID() : int+ Query() : Query+ TECUserID() : int+ TimeStamp() : byte[]

-r_query

-q_Event-q_Entity

Figura 4.2: Oggetti Serializzabili


Avere la logica sul client non garantisce che l’applicativo utilizzi sem-pre la versione più aggiornata dei metodi e in caso di aggiornamento deimetodi sul server è necessario provvedere a riavviare gli applicativi clientonde evitare comportamenti indesiderati. Questo esclude la possibilità diutilizzare gli oggetti di tipo CAO. Riguardo gli oggetti SAO, dato che sivogliono fornire servizi indipendenti ai diversi client ed essi non devonocondividere uno stato comune, si è scartata anche la possibilità di uti-lizzare gli oggetti di tipo Singleton. La scelta finale ricade dunque neglioggetti SAO SingleCall.

Il Listener sarà composto da una unica classe Listener, che conterràl’elenco di tutti gli oggetti SAO SingleCall richiamabili dagli applicativiclient. Ognuno di tali oggetti implementerà l’interfaccia per consentire lechiamate remote da client. La struttura base del listener è riportata inappendice C.

In questa tesi sono state sviluppate, oltre al listener, le classi QueryLo-cal che implementa l’interfaccia IQuery, EventLocal che implementa l’in-terfaccia IEvent, ResultLocal che implementa l’interfaccia IResultAdmin,EntityLocal che implementa l’interfaccia IEntity.

L’interfaccia IQuery permette le operazioni di aggiunta, modifica edeliminazione di una query su database. Essa permette inoltre di ritornareun oggetto serializzabile Query al client. L’interfaccia IEvent permette diaggiungere, modificare ed eliminare un evento su database. Essa inoltrepermette di ritornare una lista di oggetti serializzabili Event al client.L’interfaccia IEntity permette di aggiungere modificare ed eliminare unentità su database. Essa inoltre permette di ritornare una lista di oggettiserializzabili Entity al client.

L’interfaccia IResultAdmin estende l’interfaccia IResult. IResult con-sente di ritornare al client un oggetto Result cercandolo per ID, ritornareuna lista di Result fornendo alcuni parametri di ricerca, ritornare il da-tatable che rappresenta il risultato, eseguire una certa query e salvare ilrisultato.

Gli altri servizi offerti dal Listener, non essendo stati sviluppati dal-l’autore, non trovano trattazione nel seguito.

Le classi QueryLocal, EventLocal, ResultLocal e EntityLocal istan-ziano al momento della creazione, l’oggetto che implementa l’interfacciaIPropertiesFramework per l’iterazione con il database.

4.1.4 Schema Logico Database (Schema Properties)

4.1.5 Stored Procedures

Le stored procedure atte all’esecuzione delle query remote sono statesviluppate in modo modulare, partendo dall’interfaccia PropertiesFra-

39 Moduli A e B

class Project

MarshalByRefObject

PropertiesFramework::EntityLocal

- propertiesFwkHandler: IPropertiesFramework

MarshalByRefObject

PropertiesFramework::Ev entLocal


«interface»

PropertiesFramework::IPropertiesFramework

+ ExecuteAndSaveResult(int?, int?, int?, int?) : bool+ ExecuteAndSaveResultAsync(int?, int?, int?) : int+ GetEnti tyList() : DataTable+ GetEventList() : DataTable+ GetQueryList(bool) : DataTable+ GetQueryResultList(int?) : DataTable+ GetRemoteQueryResult(int?, string, int?) : DataSet+ GetSavedQueryResult(int?, int?) : DataSet+ GetSavedResult(int?) : DataTable+ SaveQuery(string, int?, int?, string, bool?, int?, int?, int?) : int+ SaveResult(int?, int?, int?, DataSet, int?) : bool

PropertiesFramework::PropertiesFrameworkImpl

MarshalByRefObject

PropertiesFramework::QueryLocal


MarshalByRefObject

PropertiesFramework::ResultLocal

- resultHandler: IPropertiesFramework

«interface»

TEC::IEntity

+ Add(Entity) : Entity+ Delete(Entity) : void+ GetAl l() : List<Entity>+ Update(Enti ty) : Entity

«interface»

TEC::IQuery

+ Add(Query) : Query+ Delete(Query) : void+ Get(string) : Query+ GetAl l() : List<Query>+ GetAl l(Event) : List<Query>+ GetByKey(int?) : Query+ Update(Query) : Query

«interface»

TEC::IResult

+ ExecuteAndSaveResult(Query, Ticket) : bool+ ExecuteAndSaveResultAsync(Query, Ticket) : void+ GetAll(int?) : List<Result>+ GetAll(Query, int?) : List<Result>+ GetByKey(int?) : Result+ GetQueryResultList(Ticket) : DataTable+ GetResult(Query, Ticket) : DataSet+ GetSavedQueryResult(Query, Ticket) : DataSet

«interface»

TEC::IResultAdmin

+ Add(Result) : Result+ Delete(Result) : Result+ Update(Result) : Result

«interface»

TEC::IEvent

+ Add(Event) : Event+ Delete(Event) : void+ GetAll() : List<Event>+ Update(Event) : Event

-resultHandler-propertiesFwkHandler-propertiesFwkHandler

-propertiesFwkHandler

Figura 4.3: Servizi offerti dal Server Listener


Ticket

PK TicketID

FK_CompanyBackupID FK_CompanyDatabaseID FK_TicketStatus TicketStatusDateFK1 FK_OwnerID TicketCreationDate TimestampChgU1 ComputCol TimestampDate

Result

PK ResultID

FK3 FK_QueryIDFK4 FK_TECUserID ExecutionResultFK1 FK_TicketID TimestampChg TimestampDateFK2 FK_BatchID Error

Batch

PK BatchID

FK3 FK_StatusID RequestTimeFK2 FK_QueryIDFK1 FK_TicketID

Status

PK StatusID

Description

TECUser

PK TECUserID

U1 NTUserName FirstName LastName EMail LastLoginDate FK_DepartmentID Active TimestampChg TimestampDate

Entity

PK EntityID

Description

Event

PK EventID

Description

Query

PK QueryID

U1 QueryDescriptionFK1 FK_EntityID SAPNote IsPublicFK3 FK_TECUserID QueryTextFK2 FK_EventID QueryOrder TimestampChg TimestampDate

Figura 4.4: Schema Logico DB (Schema Properties)

mework e sviluppando i moduli sottostanti.Data la necessità di eseguire query non note a priori, con result set non

noto a priori e con server\istanze che possono cambiare dinamicamente,si è fatto uso di Dynamic Sql. A fronte di una maggiore flessibilità glisvantaggi maggiori sono il problema di SQL injection e l’uso di EXEC()per query pass-through che non possono essere ottimizzate dal query plan.

Il problema di SQLInjection non rientra nei presupposti di utilizzo,in quanto i consulenti hanno comunque accesso a SSMS. Le query sonosempre e comunque manipolate da utenti con il dovuto training per l’u-tilizzo delle medesime. Non utilizzare il DynamicSql significa comunquedover spostare parte della logica all’esterno del database (ad esempio incodice di alto livello C#). Questo non aumenta la velocità di esecuzioneed inoltre costringe a gestire le transazioni dall’esterno del database. Lestored procedure più significative per lo sviluppo del MODULO A sonoqui riportate.

[Properties].[LinkedServerConn]

La stored procedure [Properties].[LinkedServerConn] crea una connessio-ne tramite linked server al database remoto selezionato sulla base dei pa-rametri in ingresso e ritorna il nome stesso del linked server. I parametridi ingresso sono:

• @intTicketID: identificativo del TEC Ticket

• @strHost: backend server

41 Moduli A e B

• @strInstance: backend instance

• @intEntityID: stabilisce se la connessione deve essere al Compa-nyDb o all’ Sbo-Common

NOTA: In caso venga aggiunto un nuovo tipo di database (detto En-tity nella SP) e sia necessario eseguire delle query su di esso, allora deveessere aggiunto nei due statement SELECT la signature del linked servere del nome del database

Si può osservare come sono stati nominati i Linked Server per:

• CompanyDb: HOST_INSTANCE_TICKETID

• SBOCommon: HOST_INSTANCE_TICKETID_COM___

La stored procedure, una volta determinato il percorso al linked ser-ver, verifica se questo è già presente nella tabella master.sys.sysservers(tabella ove vengono memorizzate tutte le connessioni a Db remoti). Nelcaso in cui un linked server non sia già presente, esso viene creato almomento.

[Properties].[GetRemoteQueryResult]

Questa SP è utilizzata per eseguire una query su un server remoto. Iparametri di input sono:

• @intTicketID: Identificativo del ticket

• @strRemoteQuery: Testo della query da eseguire

• @intEntityID: Il target della query ( Company-Db o SBO-COMMON)

Questa query richiama [Properties].[GetHostInstance] per recuperarel’host e la istanza in cui il database è stato ripristinato. Quindi richiama[Properties].[LinkedServerConn] per acquisire il nome del linked server edinfine richiama [Properties].[ExecRemoteQuery] per eseguire la query sulserver remoto e tornare il dataset contenente il risultato.

[Properties].[GetSavedQueryResult]

Questa query esegue una query su linked server remoto e torna il risul-tato. A differenza di [Properties].[GetRemoteQueryResult], la query daeseguire in questo caso è salvata su db. Tale SP è pensata per l’esecu-zione di query ricorrenti, ossia query comunemente eseguite durante leprocedure di pre/post-restore, pre/post-backup. Gli unici parametri diingresso sono in questo caso il TicketID e il QueryID. L’uscita è data dalResult Set.


GetHostInstance

strHost strInstance

intTicketID

LinkedServerConn

ExecRemoteQuery

strLinkedServer

RESULTSET ( xml representing a datatable )

intTicketID strRemoteQuery GetRemoteQueryResultintEntityID

EntityID: 1 – CompanyDB 2 – SBOCOmmon

Figura 4.5: Stored Procedure GetRemoteQueryResult

[Properties].[GetHostInstance]

Questa SP è una semplice query che prende come parametro di ingresso ilTicketID e ritorna l’Host e l’Istanza in cui il database è stato ripristinato.

[Properties].[ExecRemoteQuery]

Questa SP è sviluppata utilizzando il Sql Server CLR per l’esecuzione delcomando EXECUTE(’strRemoteQuery’) AT [strLinkedServer], ovverosiaper eseguire una query su linked server remoto e acquisirne il risultato.è stato necessario in questo caso ricorrere all’uso del CLR in quanto SqlServer non lascia nidificare 2 comandi EXECUTE.

Le due possibili soluzioni erano l’uso del CLR o l’uso della SP disistema sp_executesql. In questo caso è stato scelto di utilizzare il CLRsolamente per la sintassi più chiara.

4.1.6 Indici

La scelta degli indici si basa sulla quantità di dati contenuti nelle diversetabelle, sui campi di ricerca più utilizzati, il grado di INSERT e UPDATEconfrontato con le operazioni di SELECT.

Nelle tabelle Event, Entity e Status è stato inserito un indice nonclustered per garantire l’unicità della descrizione (Description).

43 Moduli A e B

intTicketID

strRemoteQuery

GetRemoteQueryResult

RESULTSET ( xml representing a datatable )

VIEW_Query

strQueryText

intTicketID intQueryID

GetSavedQueryResult

SELECT performed

intEntityID

Figura 4.6: Stored Procedure GetSavedQueryResult

Per comprendere come impostare gli indici nelle rimanenti tabelle sideve fare riferimento alle operazioni eseguite dalle stored procedure:

• GetBatch: Accede in scrittura a tutte le colonne e torna l’ID cor-rente.

• GetBatchList: Ricerca per QueryID e TicketID su tabellaBatch.

• GetEntityList, GetEventList eseguono una select completa.

• GetHostInstance esegue una ricerca per TicketID su Pro-perties.VIEW_TicketCompanyDbBackend

• GetQueryList accede a Properties.VIEW_Query con chia-ve di ricerca IsPublic e QueryText.

• GetQueryResultList accede a Properties.VIEW_QueryResultcon chiave di ricerca in TicketID

• GetResult accede a Properties.VIEW_Result con chiave di ricercain ResultID

• GetSavedQueryResult accede a Properties.VIEW_Query con chia-ve di ricerca in QueryID


• LinkedServerConn accede alla tabella di sistema master.sys.sysserverscon chiave di ricerca in srvname

• SetBatch accede in scrittura alla colonna FK_StatusID di Proper-ties.Batch con chiave di ricerca in BatchID

• SetQuery accede in scrittura a tutte le colonne e torna l’ID corrente

• SetQueryResult richiama SetQuery e SetResult

• SetResult accede a VIEW_Result in scrittura su tutte le colonne etorna l’ID corrente

Nella lista sopraindicata sono indicate in grassetto le condizioni chesuggeriscono l’aggiunta di un indice.

Su Batch viene aggiunto un indice non cluster per QueryID e Ticke-tID, dato che l’indice clustered è impostato su BatchID.

Gli indici sulle viste (come nel caso di VIEW_TicketCompanyDbBackend)offrono miglioramenti se le tabelle sottostanti sono scarsamente aggiorna-te [9]. Questa situazione è verificata nella vista VIEW_TicketCompanyDbBackendche accede a Properties.VIEW_HostInstance, Core.CompanyDatabase eCore.Ticket. Properties.VIEW_HostInstance e Core.CompanyDatabasesono ad alta lettura ma basso tasso di INSERT e UPDATE praticamentenullo. Core.Ticket ha la chiave primaria su TicketID che è intero auto-incrementante. Per quanto detto una indicizzazione è opportuna.

VIEW_Query riflette la tabella Query e accede ad una elevata quan-tità di dati, equivalente ad una select * per cui non ha senso eseguire unaindicizzazione.

VIEW_QueryResult esegue una ricerca per TicketID, dove TicketIDè salvato sulla tabella Result. In questo caso, invece di inserire un indi-ce sulla vista,è più opportuno indicizzare direttamente la tabella Resultaggiungendo un indice su TicketID di tipo unclustered, che ammetta du-plicati.

Nel caso della tabella di sistema master.sys.sysservers, dato che i lin-ked server saranno potenzialmente molti, la colonna srvname, utilizzatadalla SP LinkedServerConn, deve essere indicizzata.

Questo conclude la fase di indicizzazione.

45 Moduli A e B

4.1.7 Triggers e Jobs

In questa sezione si valuta l’eventuale inserimento di triggers e Sql Jobs.

L’unica operazione che non può essere realizzate tramite il modellorelazionale in oggetto è quella di controllare che le query siano inserite,modificate ed eliminate da TECAdmin.

Questo si può ottenere modificando il modello logico del databaseoppure inserendo un trigger per le operazioni INSERT / UPDATE /DELETE nella tabella Query o inserendo un controllo su tutte le storedprocedure che accedono a tale tabella.

• La modifica alla struttura del database è sconsigliata dato che altreinterfacce di accesso si basano sulla struttura attualmente in uso.

• Inserire un controllo sulle Stored Procedure che accedono alla tabel-la è altresì sconsigliato in quanto questo significa assicurare che tut-te le query sviluppate debbano contenere gli stessi controlli. Inoltre,il controllo che si vuole implementare è una proprietà sulla tabellae non sulle SP che vi accedono.

• L’uso del trigger è suggerito in quanto la tabella sarà utilizzataprevalentemente per operazioni di lettura (SELECT) e in modominoritario per UPDATE e DELETE. Tale soluzione svincola glisviluppatori DBA dal dover definire di volta in volta i controlli chedevono essere eseguiti sulla tabella query.

Per quanto esposto, è stato inserito un trigger per le operazioni diINSERT, UPDATE e DELETE nella tabella [Properties].[Query]. Perpoter garantire che il DELETE venga effettuata esclusivamente da unTECAdmin, questa operazione è stata inglobata nella stored procedure[Properties].[DeleteQuery] e preceduta da una operazione di UPDATEriportante l’userID di chi sta effettuando l’operazione.

La struttura base del trigger è la seguente:1 CREATE TRIGGER [Properties].[tgr_AdminExclusiveAllowance]2 ON [Properties].[Query]3 FOR INSERT, UPDATE, DELETE4 AS5

6 DECLARE @intCurrentID int7

8 IF EXISTS(SELECT FK_TECUserID FROM INSERTED)9 AND EXISTS(SELECT FK_TECUserID FROM DELETED)10 BEGIN11 PRINT ’UPDATE’;12

13 IF -- Is admin or manager14 BEGIN


15 -- Complete update16 RETURN17 END18 ELSE19 BEGIN20 ROLLBACK21 RETURN22 -- EXIT POINT23 END24

25 END26

27 IF EXISTS(SELECT * FROM INSERTED) -- Is an INSERT28 BEGIN29 PRINT ’INSERT’;30

31 IF -- Is admin or manager32 BEGIN33 -- Complete admin34 RETURN35 END36 ELSE37 BEGIN38 ROLLBACK39 RETURN40 -- EXIT POINT41 END42 END43 ELSE44 PRINT ’DELETE’;45 -- delete is always executed. Must be combined in46 -- Properties.DeleteQuery

La tabella RESULT contiene potenzialmente una elevata quantità didati e deve quindi essere valutata una strategia per mantenere esclusiva-mente le informazioni rilevanti.

Le possibili soluzioni sono:

• Utilizzare il partizionamento delle tabella, per spostare risultatiassociate a ticket chiusi su una tabella di archivio (per esempioResultArchive).

• Inserire un trigger nella tabella Core.Ticket che elimina I risultatisulla tabella RESULT ogni qual volta un ticket viene settato nellostato chiuso

• Creare un Sql Job per cancellare I risultati nella tabella RESULTper tutti i ticket con stato chiuso.

La soluzione da adottare si basa sulle seguenti considerazioni:

• Mantenere una tabella partizionata [20] è sconsigliato in quantodatabase associate a ticket chiusi verranno eliminate nell’arco dipoco tempo e quindi I risultati salvati non sono più di alcuna utilità.

47 Moduli A e B

Esiste la possibilità che un ticket venga riaperto ma questo si verificanel 5% dei casi, condizione per cui non si giustifica il mantenimentodi un archivio dei risultati pregressi.

• Un trigger garantisce che i risultati vengano eliminate non appenail ticket viene posto in stato ’Dropped’ ma ha lo svantaggio di essereesoso in termini di risorse.

• Un Job Sql può essere impostato per eliminare I risultati di ticketchiusi e può essere eseguito in orari in cui il server non è utilizzatoin maniera intensiva. Il Job richiede meno risorse di un trigger ed èpossible impostare la frequenza con cui esso debba essere eseguitosulla base del carico di lavoro sul server. Dato che l’eliminazioneimmediate alla chiusura del ticket non è un requisito fondamentale,l’implementazione è stata fatta tramite Sql Job.

Si faccia riferimento al Sql Job [Properties].[DeleteResultsWithDroppedTicket]per l’implementazione.

4.1.8 Transazioni

Le stored procedure non sono di per sè transazionali e deve pertanto esserecondotta una verifica per ciascuna stored procedure al fine di individuareil livello di isolamento più opportuno, tenuto conto delle proprietà diatomicità, consistenza, isolamento e persistenza delle transazioni [16],secondo la figura seguente:

Figura 4.7: Livelli di Isolamenteo [16]

In tabella 4.1 sono stati analizzati, stored procedure per stored pro-cedure, i fenomeni permessi sulla base dei quali è stato scelto il livellodi isolamento in grado di soddisfare le restrizioni imposte usando comeriferimento per la scelta la tabella di figura 4.7.


Per una descrizione più dettagliata dei livelli di isolamento si rimandaalla lettura di [7].

49 Moduli A e B

Stored

Procedu

rePha

ntom

sNon

Rep

et.Read

Dirty

Read

Lost

Upd

ates

Transaction

GetBackend

Roo

tList

Allo

wed

Allo

wed

Not

Allo

wed

Not

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

Reset

Allo

wed

Allo

wed

Allo

wed

Allo

wed

READ

UNCOMMIT

TED

SetD

irectory

Allo

wed

Allo

wed

Allo

wed

Allo

wed

READ

UNCOMMIT

TED

SetF

ileAllo

wed

Allo

wed

Allo

wed

Allo

wed

READ

UNCOMMIT

TED

SetServer

Allo

wed

Allo

wed

Allo

wed

Allo

wed

READ

UNCOMMIT

TED

DeleteQ

uery

Allo

wed

Allo

wed

Not

Allo

wed

Not

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

ExecR

emoteQ

uery

Not

Allo

wed

Not

Allo

wed

Not

Allo

wed

Allo

wed

SNAPSH

OT

GetBatch

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

GetBatchList

Allo

wed

Allo

wed

Not

Allo

wed

Not

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

GetEntityL

ist

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

GetEventList

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

GetHostInstanc

eNot

Allo

wed

Not

Allo

wed

Not

Allo

wed

Allo

wed

SNAPSH

OT

GetQue

ryList

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

GetQue

ryResultL

ist

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

GetRem

oteQ

ueryResult

Not

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

SNAPSH

OT

GetResult

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

GetSa

vedQ

ueryResult

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

–Not

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

–Not

Allow

edAllow

edNot

Allow

edAllow

edSN

APSH

OT

Link

edSe

rverCon

nAllo

wed

Allo

wed

Not

Allo

wed

Allo

wed

–Not

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

–Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

–Not

Allow

edAllow

edNot

Allow

edAllow

edSN

APSH

OT

SetB

atch

Allo

wed

Allo

wed

Not

Allo

wed

Not

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

SetQ

uery

Allo

wed

Allo

wed

Not

Allo

wed

Not

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

SetQ

ueryResult

Allo

wed

Allo

wed

Not

Allo

wed

Not

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

SetR

esult

Allo

wed

Allo

wed

Not

Allo

wed

Allo

wed

READ

COMMIT

TED

SNAPSH

OT

Tab

ella

4.1:

Ana

lisid

elle

Transazioni


4.1.9 IO Risultati da server

Il risultato di una query deve essere salvato su server. Le query chetipicamente vengono eseguite, sono query utilizzate per acquisire infor-mazioni relative al database come la versione, eventuali incongruenze diinventario, problemi di riconciliazione, ... .

Per un esempio di query da eseguire prima della fase di upgrade si fac-cia riferimento agli script 7_PreUpgradeCheck.sql e 17_IVUPreCalcula-tionExample.sql (forniti dall’IBD). La prima query è di tipo informativo(tipi string con riferimento alle SAP Note), mentre la seconda fornisceinformazioni circa i beni d’inventario affetti da anomalie.

I risultati tipicamente attesi sono dunque query multi dataset connumero di colonne compreso tra 0 e 20 e circa 10 - 1000 righe. Le dimen-sioni di una tabella sono massimo 20000 campi (informazioni acquisiteda interviste con l’IBD).

In base alla tipologia di result-set da manipolare si è valutato comequesti debbano essere salvati su server. Le possibilità analizzate sonostate 3:

• Creare a runtime una tabella risultato per ogni risultato fornitodalla query

• Salvare i dati in formato XML

La seconda soluzione introduce un overhead nei dati salvati in quantoessi sono accompagnati dallo schema xml (non essendo possibile stabili-re a priori lo schema del result-set, è necessario salvarlo congiuntamenteai dati) e dai tag che ne descrivono la formattazione. Il vantaggio stanella possibilità di caricare i dati su un datatable (o un dataset nel casodi risultati multipli) il quale può essere associato ad un datagrid per lavisualizzazione. Con la prima soluzione si eviterebbe di salvare i dati conoverhead ma i risultati verrebbero salvati in tabelle distinte, disgiunte traloro, senza alcun legame con le query che li hanno gestiti se non tramiteriferimenti alle tabelle, salvati come campi di tipo testo. Questo è contro-indicato in quanto si ignorerebbe la prima Regola di Codd, qui riportata:

[4, 1. Information RuleData is presented only in one way. As values in columns in rows. Simple,consistent and versatile. A table (aka an entity or relation) is a logicalgrouping of related data in columns and rows. Each row (aka record ortuple) represents a single fact and each row contains information aboutjust one fact. Each column (aka field or attribute) describes a single pro-perty of an object. Each value (datum) is defined by the intersection of

51 Moduli A e B

column and row. ]

Un risultato di esecuzione può essere visto come dato omogeneo, ilfatto di salvare dati omogenei su tabelle diverse scorrelate tra loro nonconviene alla prima regola di Codd. Per quanto detto si è decisa unaimplementazione con salvataggio dei dati in formato XML.

Data una query, questa viene salvata all’interno di un SqlCommandil quale viene a sua volta incapsulato in un SqlDataAdapter per fornireil risultato sottoforma di Dataset:

1 SqlCommand cmd = new ...2 SqlDataAdapter adapter = new ...3 DataSet dataSetResult = new ...4 [...]5 adapter.SelectCommand = cmd;6 adapter.Fill(dataSetResult);

Il dataset può quindi essere analizzato per estrarre le tabelle, ognunadelle quali rappresenta un risultato.

1 DataTable selectedDT = dataSetResult.Tables[indexTable];

I dati in formato XML vengono quindi estratti e salvati in uno streamin memoria

1 MemoryStream memXmlStream = new ...2 DataTable selectedDT = dataSetResult.Tables[indexTable];3 selectedDT.WriteXml(memXmlStream, XmlWriteMode.

WriteSchema);

Si noti come lo stream venga salvato accompagnato dallo SchemaXML dei dati contenuti. L’esempio di un risultato salvato su server èriportato in figura:

1 <NewDataSet>2 <xs:schema xmlns="" xmlns:xs="http://www.w3.org/2001/

XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" id="NewDataSet">

3 <xs:element name="NewDataSet" msdata:IsDataSet="true"msdata:MainDataTable="Table2" msdata:UseCurrentLocale="true">

4 <xs:complexType>5 <xs:choice minOccurs="0" maxOccurs="unbounded">6 <xs:element name="Table2">7 <xs:complexType>8 <xs:sequence>9 <xs:element name="Version" type="xs:int"

minOccurs="0" />10 </xs:sequence>


11 </xs:complexType>12 </xs:element>13 </xs:choice>14 </xs:complexType>15 </xs:element>16 </xs:schema>17 <Table2>18 <Version>860035</Version>19 </Table2>20 </NewDataSet>

Lo schema XML viene a sua volta utilizzato per creare un oggetto ditipo SqlXml per essere salvato su DB:

1 SqlParameter tmpParam = null;2 [..]3 tmpParam = new SqlParameter("@xmlExecutionResult",

SqlDbType.Xml);4 tmpParam.Value = new SqlXml(memXmlStream);5 cmd.Parameters.Add(tmpParam);

Allo stesso modo i risultati salvati in formato XML vengono carica-ti da DB e il datatable viene ricostruito sulla base dello schema che liaccompagna:

1 SqlXml xmlResult = null;2 SqlDataReader rdr = ...3 xmlResult = rdr.GetSqlXml(0);4 XmlReader xmlReader = xmlResult.CreateReader();5 DataTable dt = new DataTable();6 dt.ReadXml(xmlReader);

Si noti inoltre che nel caso insorga il problema di gestire resultsetcon dimensioni più esose è possibile usare uno FileStream invece di unMemoryStream e quindi salvare direttamente su disco senza caricare inmemoria. Lato client, il risultato verrà visualizzato su un DataGridViewtramite il comando:

1 Result tmpResult = ...2 dataGridViewResult.DataSource = tmpResult.ExecutionResult

dove tmpResult.ExecutionResult ritorna il DataTable remoto, prece-dentemente caricato con i comandi sopradescritti.

4.2 MODULO C

Il Modulo C fa uso dell’applicativo BackupManager e dello script diShrink Distribuito.

53 MODULO C

4.2.1 Applicazione BackupManager

ServerManager rappresenta la console grafica che si occupa di raccoglie-re le informazioni dai server (server, cartelle e file contenuti) e salvar-le su database. In figura 4.9 è rappresentata la classe ServerManager,che fa uso della classe BackupManager la quale contiene 2 metodi sta-tici GetBackendRootList per recuperare da server l’elenco dei server eil metodo FillBackupManagerIntoDb per salvare su Db i dati raccolti.Questo secondo metodo ha come parametro d’ingresso la lista dei ser-ver precedentemente inizializzata. Si noti che BackupManager non siinterfaccia direttamente col database, ma fa uso della implementazioneBackupManagerFramework di IBackupManagerFramework.

Figura 4.8: Interfaccia con la Base Dati per Backup Manager

In figura 4.8 è riportato il diagramma delle classi che rappresen-ta le entità Server, Folder e File. Si noti come tale diagramma derividirettamente dal modello ER del database descritta alla sezione 3.1.3.

4.2.2 Shrink Distribuito

L’operazione di shrink deve essere eseguita su server Sql2000 e Sql2005(ed essere compatibile con la futura versione Sql 2008).

Dato che l’interrogazione dei database deve avvenire su tutti i serversono state analizzate diverse possibilità tra cui:

• Il Multi Server Management di Sql Server 2008 che però non ècompatibile con le versioni precendenti di Sql Server

• Il CLR (Common Language Runtime) di Sql Server 2005 può essereadattato per l’esecuzione di operazioni su server 2008, 2005 e 2000ma sarebbe utilizzato con classi di alto livello quali SqlConnection,SqlComman per cui risulta equivalente ad un applicativo esterno.


class Class Model

«interface»

IFile

+ GetFileType() : string+ GetFolder() : IFolder+ GetName() : string

«interface»

IFolder

+ GetCreationDate() : DateTime+ GetFileList() : List<IFile>+ GetFolderInfo() : DirectoryInfo+ GetLastModification() : DateTime+ GetName() : string+ GetNumberOfFiles() : int+ GetServer() : IServer

«interface»

IServer

+ GetFolderList() : List<IFolder>+ GetName() : string+ GetRoot() : string

File

- fi leName: string- fi leType: string- parentFolder: IFolder

+ File(IFolder, string, string)+ GetFileList(IFolder) : List<IFile>+ GetFileType() : string+ GetFolder() : IFolder+ GetName() : string- recursiveSearch(IFolder, List<IFile>*) : void

Folder

- dirInfo: DirectoryInfo- fi leList: List<IFi le>- parentServer: IServer

+ Folder(IServer, DirectoryInfo)+ GetCreationDate() : DateTime+ GetFileList() : List<IFile>+ GetFolderInfo() : DirectoryInfo+ GetFolderList(IServer) : List<IFolder>+ GetLastModification() : DateTime+ GetName() : string+ GetNumberOfFi les() : int+ GetServer() : IServer

Serv er

- folderList: List<IFolder>- name: string- root: string

+ GetFolderList() : List<IFolder>+ GetName() : string+ GetRoot() : string+ Server(string, string)

-parentServer

-parentFolder

Figura 4.9: Interfacce e Implementazioni per Backup Manager

55 MODULO C

• SMO (Sql Management Object) consente l’accesso a Sql2000 e Sql2005ma la gestione avviene da un applicativo esterno e quindi assimila-bile al CLR.

• I linked server garantiscono compatibilità con Sql 2000, 2005 e 2008.Vengono implementati a livello database, consentono l’accesso re-moto ai server, offrono la possibilità di eseguire query distribuite,possono eventualmente essere estesi per l’utilizzo con data sourcedifferenti (ma risultano ottimizzati per l’impiego con provider didati sql server). Lo svantaggio principale risiede nella configurazio-ne dell’ambiente distribuito, che deve essere fatto su ogni server (siveda lo script Project.sql) e nella maggior complessità delle querydistribuite.

Si è scelto di sviluppare lo script ricorrendo ai LinkedServer, in quan-to a fronte di una maggiore complessità di computazione, la velocità diesecuzione risulta più elevate grazie ai piani di esecuzione che vengonoottimizzati da Sql Server una volta che lo script è memorizzato comeStored Procedure o Job.

A questo punto, una volta configurati I linked server per il supportoalle query distribuite resta da definire la modalità di interrogazione deivari database.

Le possibilità sono:

• Collegamento ai linked servers uno dopo l’altro ed esecuzione dellaprocedura di shrink nell’ordine in cui vengono trovati I database

• Collegamento ai linked server uno dopo l’altro, acquisizione di in-formazioni circa lo spazio che è possible liberare da ogni database,ordinamento dei DB per spazio avibile decrescente ed esecuzionedella procedura di shrinking secondo il nuovo ordine.

I vantaggi della prima soluzione sono:

• la necessità di collegarsi una sola volta ad ogni linked server

• non è necessario interrogare ogni sinolo database per acquisire in-formazioni circa lo spazio allocate che è possible liberare

• minor tempo necessario per implementare la soluzione

Gli svantaggi sono

• necessità di eseguire lo shrink su tutti I database in quanto non ènota la quantità di spazio liberabile tramite la procedura di shrink

• lungo tempo di attesa prima che venga processato l’ultimo server


I vantaggi offerti dalla seconda soluzione sono:

• Possibilità di definire l’operazione di shrink solo per database chesuperano una certa soglia di spazio allocato che è possibile liberare.Questo garantisce che lo shrink venga eseguito solamente sui data-base che realmente offrono un vantaggio in termini di spazio deal-locabile. Si ricorda infatti che un database di medie-grosse dimen-sioni (40 - 100 GB) appena ripristinato avrà poco spazio allocatoma l’operazione di shrink sarà comunque lunga.

• Possibilità di raccogliere alter informazioni durante l’operazione dishrink

Ipotizzando una equidistribuzione dei database nei vari server (comeeffettivamente è) l’operazione di shrink viene effettuata su diversi servergià nelle prime fasi dell’elaborazione e non c’è più ordinamento sequen-ziale dei server. Questo significa che se uno dei server con meno spazioa disposizione contiene database con elevato spazio allocato che si puòliberare, esso verrà posizionato in testa alla coda di elaborazione.

Gli svantaggi risultano:

• Overhead introdotto nella prima fase per la raccolta dati databaseper database

• Necessità di connessione a linked server alternati, che rallenta iltempo di esecuzione (fattore questo non significativo dato che loshrink è operazione molto più dispendiosa in termini di tempose comparata al tempo necessario alla connessione ad un linkedserver).

• Maggior complessità computazionale

• Necessità di diversificare la modalità di calcolo dello spazio allocatoper server sql server 2000 e sql server 2005 in quanto differenti.

Lo script DistributedShrink_V2.sql riporta l’implementazione dell’o-perazione di shrink. La logica dell’algoritmo e le scelte adottate sono quidescritte:

Lo script di shrinking distribuito esegue in 5 fasi:

1.Raccolta Linked ServersCrea una temporary table contenente le informazioni essenziali per ac-cedere ai server quali nome e istanza del server, nome del linked serverassociato al server\istanza, l’indicazione se il server e l’istanza sono atti-vi e un campo ConnectionError per stabilire se la connessione al linked

57 MODULO C

server ha esito positivo o meno. Tutti i linked server vengono controllatitramite la SP di sistema sp_testlinkedserver per verificarne il correttofunzionamento. In caso di errore il campo ConnectionError viene po-sto ad 1. Solamente le istanze che hanno superato il test di connessionevengono inserite nella tabella temporanea delle istanze attive #tmpActi-veInstances.

2. Raccolta informazioni da ogni serverViene creata la tabella #tmpDbStatistics dove vengono salvate le infor-mazioni relative a tutti i database presenti sui server precedentementeselezionati. In questo caso è stato necessario considerare se il server inoggetto è un server SQL2000 o SQL2005. Questo perché le informazionirelative agli oggetti contenuti nel server si possono avere interrogandooggetti del master database differenti (la tabella di sistema sysaltfiles ela tabella sysdatabases su SQL 2000, la vista sys.master_file e la vistasys.systemdatabases su SQL2005). In ambo i casi le dimensioni del data-base sono memorizzate come numero di pagine da 8KB. Le informazionivengono reperite tramite l’esecuzione di query dinamica, con la SP disistema sp_executesql.

3. Raccolta informazioni da ogni databaseDurante questa fase vengono raccolte informazioni relative allo spazioallocato non utilizzato da ogni database (oggetto della successiva fasedi shrink). SQL Server mette a disposizione in questo caso la storedprocedure sp_spaceused [8]. Il problema consiste nel fatto che tale storedprocedure contiene più di un result set. La direttiva INSERT INTO puòessere usata in combinazione con una stored procedure solo se questarestituisce un unico result set, altrimenti non è possibile gestirla. Inquesto caso si è deciso di implementare manualmente lo script equivalentealla SP sp_spaceused in modo da tornare un solo result set. Anche inquesto caso la query da eseguire differisce tra SQL2000 e SQL2005.

E’ importante ricordare che eseguire query sulle system table è unaoperazione non supportata da Microsoft. Microsoft può e cambia le in-formazioni qui salvate da release a release. In caso di upgrade è compitodel programmatore provvedere al riallineamento dei dati [13]. Tale que-ry calcola lo spazio occupato dal database (@dbsize), i bytes per pagina(@bytesperpage) e il totale delle pagine allocate. La differenza tra le di-mensioni totali del database e le pagine realmente allocate dagli oggettici da lo spazio allocato non utilizzato. Una volta terminata tale proce-dura i dati di tutti i database attualmenti presenti nei server si trovanoall’interno della tabella temporanea #tmpDbUnallocatedSpace.

4. Integrazione con Backup Manager


I dati relativi ai database presenti su server vengono copiati all’internodella tabella [BackupManager].[RestoredDatabase]. Tale operazione nonriguarda l’operazione di shrinking ma permette di combinarla con l’o-perazione di controllo delle directory su server, minimizzando l’uso deiprocessi in esecuzione sui server.

5. ShrinkingI database vengono ordinati per spazio allocato non utilizzato decrescen-te e viene effettuata l’operazione di shrinking solamente per i databasecon spazio allocato non utilizzato sopra una certa soglia (in MB) stabi-lita dall’utente. La procedura inizia controllando che il database non siail tempdb. In tal caso esegue il comando sp_dboption [10] con l’opzio-ne ’trunc. log on chkpt.’ per troncare il transaction log fino all’ultimocheckpoint (restore). Si noti che il processo di compattazione non ha loscopo di migliorare le prestazioni del database (in realtà le peggiora inquanto la successiva operazione di inserimento o aggiornamento richie-derà un incremento della dimensione del file dati che si traduce in unarichiesta di spazio su disco da parte del DBMS al sistema operativo) maha il solo scopo di liberare spazio dal sistema. La successiva operazione èquella di impostare per ogni database (eccetti master e tempdb) l’opzioneAUTOSHRINK attiva, il che consente di compattare automaticamenteil database ad intervalli regolari. Viene quindi eseguita l’operazione diShrink vero e proprio (comando SHRINKDATABASE) con le opzioniTRUNCATEONLY e NO_INFOMSGS. TRUNCATEONLY garantisceche lo spazio non allocato venga rilasciato (invece che compattato). Sinoti che solo i file dati sono troncati, mentre i file di log non sono inte-ressati da tale operazione. Per quanto appena detto, si rende necessariaanche una operazione di shrink dei file di log, tramite il comando SH-RINKFILE per tutti i file di log attualmente in uso.

Tale script è stato pensato per essere eseguito come Sql Server Jobschedulato alle ore 20.00 GMT, ossia quando vi è il minor numero diutenti connessi e quindi minor uso dei server.

4.2.3 Schema Logico Database (Schema BackupManager)

Viene qui riportato lo schema logico della parte di database afferente alloschema BackupManager.

Le stored procedures che si interpongono tra l’interfaccia IBackup-ManagerFramework e le tabelle Backend Server,Directory e File sono:

• [BackupManager].[Reset] per eliminare il contenuto delle sud-dette tabelle

59 MODULO C

• [BackupManager].[SetServer] per inserire Nome e Root di ogniserver ritornando il ServerID

• [BackupManager].[SetDirectory] per inserire ServerID, nome,data di creazione, data di ultimo accesso, numero di file della car-tella ritornando il Directory ID

• [BackupManager].[SetFile] per inserire nome, estensione, Direc-tory ID della cartella di appartenenza e ritornando il File ID.

• [BackupManager].[GetBackendRootList] è utilizzata per re-perire le informazioni relative ai server e alle rispettive root di-rectory di backup durante la prima fase di raccolta informazioni.Questa stored procedure allo stato attuale si appoggia alla tabella[BackupManager].[BackendRootList].

La tabella [BackupManager].[RestoredDatabase] non ha alcuna rela-zione diretta con le tabelle BackendServer, Directory e File. Essa vieneaggiornata ad ogni esecuzione dello script di Shrinking (pensata comeoperazione OLAP).

L’elenco delle directory che non sono associate a nessun database ven-gono visualizzate dalla vista [BackupManager].[VIEW_OrphanDirectory]la quale effettua una operazione di confronto tra le tabelle Directory,BackendServer e la tabella dbo.CustomerDatabase.

BackendServer

PK BackendServerID

HostName BackupRoot

Directory

PK DirectoryID

Name CreationTime LastAccessTime NumFilesFK1 FK_BackendServerID

File

PK FileID

Name TypeFK1 FK_DirectoryID

RestoredDatabase

server_type linked_server database_name database_size unallocated_space

Figura 4.10: Schema Logico DB (Schema BackupManager)


Il risultato fornito dalla vista dopo una esecuzione dello script diShrink e dell’applicativo BackupManager è riportato in figura 4.11.

Figura 4.11: Directories orfane

Lo script 2_BackupManager_DataAnalysis.sql permette di rilevaredatabase replicati (ossia database con stesso nome allocati su moltepliciistanze) e i database che non corrispondono a nessun Ticket registrato.Una esecuzione di tale script ha portato in luce l’esistenza di 568 data-base replicati e 68 database non associati ad alcun ticket, per uno spazioallocato eguale a circa 59Gb, come mostrato in figura 4.12.

L’eliminazione delle cartelle orfane è operazione eseguita da un TECAdmindopo opportuna verifica (devono infatti essere escluse le cartelle afferentiai DemoDatabase). Lo script utilizzato per tale operazione è 16_Dele-teOrphanDir.sql.

4.3 MODULO D

In questa sezione viene descritto come implementare la modifica al work-flow proposto, riportato in figura 3.15.

Per implementare il modulo di Forced Upgrade Process (FUP) devonoessere definito un [Properties].[EVENT] a livello DB per ognuna dellesezioni GSC (sezioni diverse possono consentire o meno l’esecuzione dideterminate query, a seconda del problema in analisi). Ogni EVENTviene registrato con una Description con prefisso ForcedUpg_ seguitadal nome della sezione GSC, ad esempio ForcedUpg_SYSTEM per l’areasistema, ForcedUpg_FINANCE per l’area finanza, e così via.

61 MODULO D

Figura 4.12: DBs non associati a Tickets


Nel momento in cui un Upgrade fallisce, il consulente può richie-dere tramite PlugIn TEC un Forced Upgrade selezionando da un elen-co l’area a cui appartiene. Il plug-in dovrà quindi richiamare tutte lequery relative all’entity opportuna e rilanciare l’upgrade (Il procedimen-to di selezione ed esecuzione delle query può essere ripreso dal plug-inIVUAutomationClient).

Per ognuno degli EVENT creati verranno aggiunte a mano a manonuove queries, concordate dall’Upgrade Solution Desk (USD). L’USD ècostituito da TECAdmin (designati dal System TeamLeader) e da membridell’IBD di differenti aree (System, Finance, Logistic, ...). Scopo dell’USDè quello di analizzare le query proposte dai System consultant e decideresu quali EVENT tale query possono essere inserite.

Nel caso in cui un Upgrade fallisca anche dopo il forced upgrade, ilSystem Consultant procederà ad analizzare e rilevare i problema. Eglipuò avvalersi delle query eseguite durante l’FUP per escludere a priorideterminate problematiche.

Una volta risolto il problema, il System Consultant informerà l’USDtramite il processo di Upgrade Issue Knowledge Transfer il quale valuteràil problema, la soluzione proposta (effettuando eventuali modifiche senecessario) e registrerà la query nelle ENTITY di rilievo.

Finito tale processo il consulente GSC verrà notificato dell’avvenutoupgrade.

I vantaggi derivanti dall’uso di questa soluzione sono:

• Minor carico di lavoro dei System Consultant a mano a mano chenuove query vengono aggiunte al sistema

• Maggior velocità di risoluzione dei problemi per i GSC Consultant:La procedura FUP risulta più veloce di un controllo manuale epermette di controllare e risolvere problemi multipli in una solaesecuzione

• Maggiore velocità di risoluzione dei problemi per i System Consul-tant, i quali possono escludere tutte le problematiche automatica-mente rilevabili dalla procedura automatica

• Knowledge transfer migliorato: I problemi rilevati durante la fasedi upgrade vengono condivisi e la soluzione proposta viene control-lata dall’IBD, che possiede maggiori informazioni circa le possibiliimplicazioni che una determinata query può avere nelle diverse aree.

I punti critici, che devono essere valutati dai diversi GTL sono:

• Modifica del workflow: è necessario modificare la pratica d’uso deiconsulenti GSC e dei System Consultants

63 MODULO D

• Maggior carico di lavoro iniziale dei System Consultants: Le queryproposte devono essere generiche, in modo da adattarsi a futuriusi piuttosto che precise per risolvere uno specifico problema su uncerto database.

• Necessità di definire i membri dell’USD e relativi compiti (controlloquery, validazione, ...).

A tal proposito si sono sviluppate le queries 6_OCRD_InconsistencyRemoval.sqle 14_RemoveDuplicatesOCPR_CRD1.sql per rimuovere alcune delle in-consistenze e duplicati che riguardano i Business Partners.

Capitolo 5Risultati ottenuti

In questo capitolo vengono riassunti i risultati raggiunti a seguito dell’im-plementazione dei moduli precedentemente progettati e sviluppati.

5.1 Moduli A e B

Il modulo relativo alla gestione delle query e dei risultati si è rilevatodi immediato utilizzo: altri sviluppatori lo hanno utilizzato per l’auto-mazione delle operazioni da effettuare immediatamente dopo il restoredi un database (Evento AfterRestore) e prima di un upgrade (EventoBeforeUpgrade).

L’autore ha inoltre utilizzato quanto sviluppato nei moduli A e B perestendere le funzionalità del Client TEC, aggiungenfo il PlugIn IVU ripor-tato in appendice, che fa uso degli eventi IVUPreRecalculation, IVUPo-stRecalculation e delle query IVU_PreRecalculation_2005, IVU_PreRecalculation_2007,Diff_OpenQty_OINM_&_Qty_OITW_OITM_FIFO, Item_Neg_Qty_&_Pos_Inv_&_Viceversa,None_Recalculated_Documents_V5.16, OpenValue_smaller_than_0_for_FIFO_items,StockDiff_OINM&OITM&OITW_07A.V1.1.

Lo schema Client-Server proposto si è rilevato conforme alle aspettati-ve, i risultati a video sono fluidi e non si ha percezione di ritardo nel trasfe-rimento dati. Il server listener è stato popolato dagli altri programmatoricon i moduli da loro sviluppati.

5.2 Modulo C

Come si può vedere dalla Figura 5.1, lo snapshot sui server è decisamentemigliorato (rispetto allo snapshot di figura 3.11): I file di backup non sonopiù presenti, i file .ldf (viola) hanno dimensioni inferiori ed è aumentato

65

5. Risultati ottenuti 66

lo spazio occupato dai file .mdf (blu) il che significa un maggior numerodi database gestiti sul server.

Figura 5.1: Snapshot Sequoia dopo lo shrink e l’eliminazione delle cartelleorfane

Inoltre, schedulando lo shrink distribuito giornalmente, lo spazio al-locato che viene liberato è di circa 70 Gb (media osservata su un arco ditempo di una settimana). Lo spazio allocato, rilasciato dall’operazionedi shrink si può ottenere dalla query:

1 SELECT SUM(unallocated_space)2 FROM [BackupManager].[RestoredDatabase]3 WHERE unallocated_space > 0

Per valutare se tale spazio sia sufficiente a garantire che i server nonvengano saturati, deve essere valutato il carico giornaliero di databaseche vengono ripristinati su server.

La permanenza media di un database su server è pari a 45 gior-ni. Recentemente vengono ripristinati circa 30 database al giorno (comeriportato dal grafico 5.2 della media mobile su 45 giorni).

Mediamente vengono cancellati circa 35 database al giorno (Fig. 5.3).Questo risultato è in accordo con il dato sulla permanenza media deidatabase sui server. Se consideriamo che la dimensione media di un da-tabase è pari a 3.5GB (più 0.5GB per il backup compresso), lo spaziogiornalmente liberato dall’operazione di shrink consente di sopperire allarichiesta di 10 database di dimensione media, pari al 33% della richiestatotale giornaliera.

La differenza tra i database ripristinati e quelli cancellati, rilevatanell’ultimo periodo, fornisce un ulteriore incremento pari a (35-30) = 5database pari al 16% della richiesta giornaliera.

67 Modulo C

Figura 5.2: Database ripristinati (media mobile su 45 gg)

Figura 5.3: Database cancellati (media mobile su 45 gg)

5. Risultati ottenuti 68

Sommando i due valori si ottiene un totale di incremento pari al 49%delle richieste. Tale valore si avvicina al guadagno di spazio pari al 41.06%rilevato dalla comparazione del report di backend nei mesi di novembre2008 e marzo 2009 (Si vedano i file BackendInfo_28_11_2008.html eBackendInfo_22_03_2009.html). La differenza tra il 49% ed il 41.06% èin parte dovuta all’allocazione di ulteriori backup eseguita da alcuni TE-CAdmin durante la fase di migrazione da TEC 3 a TEC 4). In figura 5.4viene riportata la differenza in percentuale tra lo spazio disponibile suserver in novembre ’08 e marzo ’09.

Figura 5.4: Guadagno di spazio (in %) sui server di backend

La bontà del risultato ottenuto trova conferma nelle richieste di sup-porto per il ripristino manuale dei database restore falliti. Come si puòosservare nel grafico di figura 5.5 le richieste sono drasticamente diminuitenel momento in cui è stato fatto il porting in produzione della soluzionedescritta (01.02.2009) nonostante i database ripristinati siano aumentati.Osservando il grafico si nota come nei periodi precedenti, all’aumentaredei database ripristinati aumentavano le richieste di supporto da parte diun TECAdmin (eccetto il 17/07/2008).

Comparando i report relativi allo spazio libero su server di Novem-bre 2008 e Marzo 2009 (si vedano i report BackendInfo_28_11_2008 eBackendInfo_22_03_2009) si ha un aumento dello spazio disponibile suserver pari a 1277Gb pari ad un incremento del 26,35%.

Lo script 5_DistributedShrink_V2.sql si è rivelato di particolare im-portanza per il modello con cui è stato costruito. Esso è infatti statoutilizzato per sviluppare altri 2 script (19_IRUProbeScript5.sql prima

69 Modulo D

Figura 5.5: Ticket richiesti e ripristini manuali

e 20_IRUProbeScript5.sql poi) richiesti da alcuni Consulenti nei tempiprevisti (5 giorni su 7 assegnati).

5.3 Modulo D

Allo stato attuale non è possibile fornire una valutazione sugli obiettivipreposti dallo sviluppo del Modulo D data la prematura fase di test incui si trova.

Capitolo 6Conclusioni eRaccomandazioni

In questo capitolo vengono riportate alcune considerazioni sorte durantela fase di sviluppo delle soluzioni ai problemi trattati.

6.1 Miglioramenti moduli A e B

Nel modulo A, si è scelto di interfacciare il datasource del DataGridViewcon il DataDataTable in quanto quest’ultimo ha la possibilità di esseregenerato a partire dallo schema in formato XML, su cui poi possonoessere caricati i dati. Il problema principale sta nella ridondanza elevataintrodotta dallo schema XML del DataTable.

La soluzione proposta non si propone comunque di sostituire tut-te le funzionalità fornite da SSMS. Il limite principale, è relativo allatrasmissione e visualizzazione di elevate moli di dati.

I possibili miglioramenti possono essere alternativamente due:

• creare uno schema xml personalizzato in cui i tag siano minimali,sostituendo ad esempio xs:element, xs:sequence, xs:choice, ... contag e, s, c. Tale soluzione ridurrebbe notevolmente la quantitàdi dati trasmessi tra gli end-point. Lato client si potrebbe quindirigenerare il DataTable con lo schema originale, riformattando loschema xml ricevuto dal server.

• creare un oggetto DataTable personalizzato, che implementi le in-terfacce IListSource ed ISerializable (o eventualmente IXmlSeria-lizable). In questo modo IListSource permetterebbe all’oggetto di

71

6. Conclusioni e Raccomandazioni 72

interfacciarsi direttamente al DataGridView. L’interfaccia ISeriali-zable permetterebbe di trasferire l’oggetto al server e di memoriz-zarlo come stream di byte o alternativamente l’interfaccia IXml-Serializable permetterebbe una funzionalità equivalente a quellaimplementata, con gli accorgimenti specificati al punto precedente.

Modificando l’XML dello schema si ridurrebbe anche la quantità didati immagazzinata sul server.

L’interfaccia IPropertiesFramework potrebbe essere scissa in differen-ti interfacce come IPropertiesQuery, IPropertiesResult, IPropertiesBatch,IPropertiesEvent e IPropertiesEntity. Questo permetterebbe agli svilup-patori di gestire oggetti che implementano un minor numero di metodieventualmente eseguendo cast diversi su IPropertiesFramework a secondadella funzionalità richiesta.

6.2 Miglioramenti modulo C

Durante la fase di Shrink distribuito, l’operazione di shrink potrebbeessere parallelizzata per eseguire su server diversi inserirendo una StoredProcedure CLR che, una volta ultimata la fase di raccolta informazionida ogni server, ricorre ad un ThreadPool per eseguire lo shrink su serverdiversi. Si noti che non è necessario parallelizzare la raccolta informazioniin quanto il tempo di tale operazione è di qualche secondo, comparatocon l’operazione di shrink (45 - 60 minuti).

6.3 Considerazioni Finali

Lo studio ha rilevato la mancanza di un supporto a livello database peril salvataggio di esecuzioni di query non note a priori su ambiente distri-buito. Tale argomento offre spunti per una ricerca più approfondita sullemodalità di gestione di tali scenari.

Appendice ARaccolta Informazioni perla gestione query

Il committente ha espresso le seguenti richieste durante la fase di raccoltainformazioni:

• Si vuole realizzare un sistema per permettere a consulenti e ammini-stratori di poter eseguire query sui database utenti. Una query puòessere eseguita sull’SBO-COMMON oppure sul COMPANY-DB delcliente. Le query possono avere più di un risultato.

• Il risultato di una query necessita di essere salvato.

• Ogni COMPANY-DB è legato ad un TEC Ticket.

• Ogni TEC Ticket può contenere al più un COMPANY-DB ed unSBO-COMMON.

• Lo script della query da eseguire può essere specificato dall’utenteoppure può essere già esistente ed associato ad una SAP Note.

• Una query può essere eseguita in un particolare momento, come adesempio subito dopo un restore, prima o dopo un upgrade, primadi un backup.

• Le query possono essere eseguite più volte su differenti ticket.

• Ogni volta che la query viene eseguita può generare un risultato oun errore.

• Ci possono essere più risultati della stessa query dovute a più ese-cuzioni, anche sullo stesso ticket.

73

A. Raccolta Informazioni per la gestione query 74

• Le query vengono eseguite sempre o sul COMPANY-DB o sull’SBO-COMMON ad esso associato.

• Non si esclude la possibilità di eseguire in futuro query su tipi diversidi database ( ad esempio certi AddOn installano un nuovo databaseche riferisce al COMPANY-DB o all’ SBO-COMMON.

• Ogni query può avere una descrizione della query stessa.

• Ogni qual volta viene modificata una tabella nel database, deveessere possibile identificare se e quando la tabella è stata modi-ficata. Questo serve data la natura asincrona dell’applicativo dasviluppare.

• Quando viene eseguito un certo task, comprendente l’esecuzione dipiu query, esso può specificare l’ordine in cui tali query vengonoeseguite.

• E’ compito del TECAdmin definire l’ordine con cui le query vengonoeseguite.

• Una certa query può essere disabilitata quando non la si vuoleutilizzare.

• Per ogni risultato deve essere possibile identificare la query che loha generato e il risultato della esecuzione deve essere salvato.

• Il risultato di esecuzione deve essere solamente analizzato. Nondevono essere fatte ulteriori query sul risultato.

• Deve essere possibile inserire, modificare e cancellare query da partedei TECAdmin.

• Deve essere possibile inserire, modificare e cancellare risultati.

In un secondo momento sono stati specificati i seguenti requisiti:

• Alcune query possono avere tempi di esecuzione lunghi (fino a 3giorni) e tali query devono essere NON bloccanti per l’appliativoclient

• Deve essere possibile controllare se una query è in esecuzione su uncerto ticket ed evitare che essa venga lanciata nuovamente nel casoquesto si verifichi

• Deve essere possibile specificare un timeout massimo di esecuzioneper le query con tempi di processamento lunghi.

Appendice BElenco degli script realizzati

• 1_BackupAllDatabases.sql : Crea un file di backup per ogni da-tabase presente nell’istanza dove lo script viene eseguito (TEC 3 oTEC 4).

• 2_BackupManager_DataAnalisys.sql : Script utilizzato per l’ana-lisi dopo aver caricato tutte le tabelle riferite dallo schema Backu-pManager. Vengono scritti a video il numero di database replica-ti, l’elenco dei database replicati, database non associati a ticket,spazio allocato dai database (TEC 3).

• 5_DistributedShrink_V2.sql : Script per eseguire l’operazione dishrink su tutti i server (Modulo C, TEC 3)

• 6_OCRD_Inconsistency_Removal.sql : Script per rimuovere inco-sistenze nella tabella OCRD (Business Partner Table). Usato nellafase di Test per il Modulo D. (TEC 3 o 4).

• 8_Project.sql : Script utilizzato durante la fase di testing (TEC 3o 4)

• 9_Properties_Script.sql: Script per aggiungere lo schema Proper-ties e le relative tabelle al database TEC 4. Usato nel porting inproduzione.

• 10_Query_MDF_LDF.sql : Script utilizzato per visualizzare l’e-lenco dei file .MDF e .LDF di tutti i database presenti nell’istanzaove lo script viene eseguito (TEC 3 o 4)

• 12_UpgradeCheck_V2.sql : Script per i membri del System TEAMche serve a verificare:

75

B. Elenco degli script realizzati 76

– tabelle presenti nel Customer-DB, che non sono presenti nelReference-DB

– tabelle presenti sia nel Customer-DB che nel Reference-DB,con campi di differente tipo\lunghezza

– tabelle presenti sia nel Customer-DB che nel Reference-DBcon campi presenti SOLO nel Customer-DB

(TEC 3)

• 14_RemoveDuplicatesOCPR_CRD1.sql : Script per rimuovere in-cosistenze nelle tabelle OCPR (Contact Persons) e CRD1(BusinessPartners - Addresses). Usato nella fase di Test per il Modulo D.(TEC 3 o 4).

• 15_Analysis.sql : Script utilizzato nella fase di analisi per il ModuloC. Visualizza:

– una tabella con Anno, Mese, Anno\Mese, Numero Db Ripri-stinati raggruppati per mese

– una tabella con Anno, Numero Db ripristinati per anno

– Una tabella con il numero di Db ripristinati giornalmente

(TEC 3)

• 16_DeleteOrphanDir.sql : script utilizzato per cancellare le cartelleorfane, alla fine della raccolta informazioni eseguita nel Modulo C.(TEC 3 o 4)

• 19_Utilities.sql : Script utilizzato per facilitare le operazioni ese-guite dal DBA durante l’attività di amministrazione di TEC (TEC3)

• 21_IRUProbeScript5.sql : Script utilizzato per generare una tabel-la con le seguenti informazioni:

– CustomerID del cliente

– Nome del cliente

– Numero del ticket

– Linked server dove si trova il database

– Nome del database

– Versione attuale del database

– Localizzazione del database

77

– Messaggio IRU (Corruzione IRU ripristinata, Corruzione IRUnon ripristinata, Corruzione IRU non presente)

– ID associato al Messaggio IRU

– Storia degli upgrade eseguiti sul database

– Indicazione se il ticket è un ticket di upgrade

Nota: Per lo sviluppo del suddetto script si sono utilizzate le que-ry fornite nel documento IBD_KP_IRU_query_Specification.docdal dipartimento Finance di SAP B1, opportunamente modificatee adattate (Il documento con le specifiche è contenuto nella cartellaIRUProbe).

Appendice CStruttura base del Listener

1

2 class Listener3 {4 TcpChannel m_tcpChannel;5 HttpChannel m_httpChannel;6

7 private void Listen()8 {9 try10 {11 // ... implements IServerChannelSinkProvider12 CompressionServerSinkProvider

compressedServerSinkProvider = new ...13

14 // ... implements IServerFormatterSinkProvider,IServerChannelSinkProvider

15 BinaryServerFormatterSinkProviderbinaryServerSinkProvider = new ...

16 [...]17 compressedServerSinkProvider.Next =

binaryServerSinkProvider;18

19 if (mySettings.Protocol.Equals("tcp")20 {21 m_tcpChannel = new TcpChannel(props, null,

compressedServerSinkProvider);22 ChannelServices.RegisterChannel(m_tcpChannel, true)

;23 }24 if (mySettings.Protocol.Equals("http")25 {26 m_httpChannel = new HttpChannel(props, null,

compressedServerSinkProvider);27 ChannelServices.RegisterChannel(m_httpChannel,

false);28 }29

30 // register here all services31 RemotingConfiguration.RegisterWellKnownServiceType(...)

;

79

C. Struttura base del Listener 80

32 [...]33

34 }35 catch (Exception ex)36 {37 [...]38 }39 }40 }

Appendice DSetup dell’ambiente di teste sviluppo

Per poter far funzionare l’ambiente di test devono essere create almeno 2istanze Sql Server 2005, così nominate:

• (local)

• (local)\INSTANCE2

Nell’istanza (local) deve essere fatto il restore del database TEC.bake rinominato TEC (TEC 4 database)

Nell’istanza (local)\INSTANCE2 deve essere fatto il restore dei data-base:

• SBO-COMMON.bak, rinominato in 105

• SBODemo_Austria_800181.bak, rinominato in 105_COM___

• SBO-COMMON.bak, rinominato in 147

• SODemo_Italy_800181.bak, rinominato in 147_COM___

Piu in generale in (local)\INSTANCE2 devono essere inserite le cop-pie DatabaseName, SBODatabaseName che appartengono all’HostName(local) e all’istanza CompanyDb_SQLInstanceName della vista Proper-ties.VIEW_TicketInstance Tali informazioni possono essere ottenute ese-guendo la query seguente sul database TEC precendetemente ripristinato:

1 SELECT TicketID, DatabaseName, SBODatabaseName2 FROM Properties.VIEW_TicketInstance3 WHERE HostName = ’(local)’ AND CompanyDb_SQLInstanceName = ’INSTANCE2’

81

D. Setup dell’ambiente di test e sviluppo 82

Dopo aver ripristinato i database, si crea un linked server all’istanza(local)\INSTANCE2 con la SP seguente:

1 EXEC sp_addlinkedserver2 @server=’(local)\INSTANCE2’, -- server_instance_database3 @srvproduct=’’,4 @provider=’SQLNCLI’,5 @datasrc=’(local)\INSTANCE2’ -- server\instance

Si abilita il supporto alle chiamate RPC su (local)\INSTANCE2 tra-mite la stored procedure di sistema

1 exec sp_serveroption @server=’(local)\INSTANCE2’, @optname=’rpc’,@optvalue=’true’

2 exec sp_serveroption @server=’(local)\INSTANCE2’, @optname=’rpc out’,@optvalue=’true’

E’ possibile verificare la corretta configurazione dei linked server tra-mite la stored procedure di sistema

1 exec sp_helpserver

Le colonne rpc ed rpc out dovrebbero essere settate ad 1 in caso laconfigurazione sia andata a buon fine. Una volta ripristinati i database,l’ambiente SSMS dovrebbe riportare una configurazione come quella infigura D.1:

Figura D.1: Configurazione SSMS

83

La succesiva operazione da effettuare è quella di registrare la StoredProcedure sviluppata in CLR, all’interno del database TEC. L’assemblygenerato dalla compilazione è SqlServerProjectCLR.dll. Ipotizzando chequesto venga posto nel drive C:\, nel database TEC precedentementeconfigurato deve essere eseguita la seguente query:

1 CREATE ASSEMBLY CLRAssembly FROM ’C:\SqlServerProjectCLR.dll’2 WITH PERMISSION_SET = SAFE3 GO4

5 CREATE PROCEDURE Properties.ExecRemoteQuery6 @strLinkedServer nvarchar(max),7 @strRemoteQuery nvarchar(max)8 AS EXTERNAL NAME9 CLRAssembly.StoredProcedures.RemoteQuery10 GO

L’ultima operazione da effettuare sul database TEC è quella di abili-tare il supporto alle transazioni di tipo snapshot, tramite il comando:

1 ALTER DATABASE TEC2 SET READ_COMMITTED_SNAPSHOT ON;3 GO4

5 ALTER DATABASE TEC6 SET ALLOW_SNAPSHOT_ISOLATION ON;

L’ambiente di test è ora configurato e può essere utilizzato con ilprogramma RemoteQueries.

RemoteQueries deve essere configurato impostando i parametri diconfigurazione nel file xml app.config.

I parametri da configurare sono:

• SQLConnectionString: Stringa di connessione al server principale(puo’ coincidere con il database (local)).

• TicketID: TicketID sul quale si vuole condurre il test

• TECUserID: UserID dell’utente che effettua le operazioni su DB

• SQLConnectionStringProperties: stringa di connessione al server ditest (tipicamente (local))

• SQLTimeOut: Timeout del server puntato da SQLConnectionString-Properties

Per verificare il funzionamento dei database di cui sopra, devono esse-re inserito nel file di configurazione il TicketID 41 (associato al Database105) oppure il TicketID 67 (associato al Database 147). L’aggiunta, mo-difica o cancellazione di query avviene soltanto se nel file di configurazioneviene impostato un TECUserID con autorizzazioni di TECAdmin o Ma-nager (come ad esempio l’user 254). In caso si utilizzi un utente con

D. Setup dell’ambiente di test e sviluppo 84

autorizzazione di TECUser (es. user 248), il sistema inibirà l’aggiunta,modifica o cancellazione di queries.

Appendice EInterfacce UtenteApplicativi

In questa sezione vengono riassunte le interfacce grafiche con cui l’utentepuò interagire.

Il progetto RemoteQueries mostra a video gli UserControl Query-Processor (Fig. E.1) e ResultAnalyzer (Fig. E.2). Queste GUI vengonoutilizzate durante la fase di sviluppo per testare l’implementazione dell’in-terfaccia PropertiesFramework prima del porting in produzione. Ognunadelle funzionalità numerate presenti in figura 3.7 trova corrispondenzanelle schermate QueryProcessor e ResultAnalyzer.

Figura E.1: GUI QueryProcessor

85

E. Interfacce Utente Applicativi 86

Figura E.2: GUI ResultAnalyzer

In particolare QueryProcessor permette di testare tutte le funzionalitàrelative al caricamento, esecuzione e salvataggio delle query e dei risultati.ResultAnalizer permette di verificare il caricamento dei dati dalla tabellaResult e i Batch di esecuzione.

La GUI del progetto ServerManager (Fig. E.3) fornisce 2 funzionalità:

• Analisi delle cartelle presenti su server (bottone COLLECT DATA)

• Salvataggio dei dati su database TEC_LIVE(bottone STORE DA-TA)

La listbox nella parte sinistra della videata, listBoxServer, visualizzal’elenco dei server da analizzare con evidenziato il server correntementesotto analisi. La listbox nella parte destra della videata, listBoxResult,visualizza l’elenco delle cartelle analizzate. La barra di stato in basso,visualizza la percentuale di server processati.

All’interno del progetto TEC sono stati sviluppate 3 interfacce grafi-che:

L’UserControl AdminQueries (Fig. E.4) permette di aggiungere o ri-muovere una query nell’evento selezionato. Per ogni query si deve spe-cificare su che tipo di database la query sarà eseguita (Performed on),si deve assegnare un titolo (Title), una Nota SAP di riferimento (SAPNote) e un ordine di esecuzione (Order). La parte destra della videatapermette di inserire il testo della query.

Il plugin DisplayQueriesPlugin (Fig. E.5), una volta selezionato unTicket sulla Dashboard di sinistra, permette di filtrare tutti i risultati

87

Figura E.3: GUI ServerManager

Figura E.4: GUI AdminQueries

salvati sul database in base al tipo di database (DB TYPE ), l’evento(EVENT ) e la query (QUERY ). Una volta selezionato il risultato tramiteil menu a tendina RESULT, clikkando su LOAD esso viene visualizzatoa video.

Il plugin IVUAutomation (Fig. E.6) permette di eseguire il pre-calcolodei beni in inventario, richiamabile con il bottone PRE-CALCULATION.

Nel caso in cui il pre-calcolo non fornisca alcun risultato, è possi-

E. Interfacce Utente Applicativi 88

Figura E.5: GUI DisplayQueriesPlugin

Figura E.6: GUI IVUAutomation

bile procedere con il riordino dell’inventario tramite il bottone POST-CALCULATION.

Nel caso in cui il pre-calcolo fornica dei risultati, l’utente può vi-

89

sualizzare i risultati selezionando l’esecuzione e il risultato di esecuzionetramite i due menu a tendina. Una volta corretti gli errori di inventariodirettamente sul database è possibile ripetere il pre-calcolo.

Si noti che il POST-CALCULATION è inibito sintantochè il PRE-CALCULATION ritorna dei risultati.

Appendice FElenco dei server gestiti

ID SERVER INSTANCE AddOn VERSION1 pwdf2412 B1_20042BADDON 1 20042 pwdf2412 B1_2004AADDON 1 20043 pwdf2412 B1_2005ASP00 0 2005 SP004 pwdf2412 B1_2005ASP01 0 2005 SP015 pwdf2412 O5B12005ASP1 0 2005 SP016 pwdf2413 B1_2004A 0 20047 pwdf2413 B1_2005ASP00ADD 1 2005 SP008 pwdf2413 B1_2005ASP01 0 2005 SP019 pwdf2413 B1_2005BSP00 0 2005 SP0010 pwdf2413 B1_2005BSP00ADD 1 2005 SP0011 pwdf2413 O5B12005ASP1 0 2005 SP0112 pwdf2413 O5B12005BSP0 0 2005 SP0013 pwdf2660 B1_2004A 0 200414 pwdf2660 B1_2005ASP01 0 2005 SP0115 pwdf2660 O5B12005ASP1 0 2005 SP0116 pwdf2681 B1_2005ASP01 0 2005 SP0117 pwdf2681 B1_2005ASP01ADD 1 2005 SP0118 pwdf2681 O5B12005ASP1 0 2005 SP0119 pwdf2681 O5B12005ASP1ADD 1 2005 SP0120 pwdf2806 B1_20042B 0 200421 pwdf2806 B1_20042BADDON 1 200422 pwdf2806 B1_2004A 0 200423 pwdf2806 B1_2004C 0 200424 pwdf2806 B1_2004CADDON 1 200425 pwdf2806 B1_2005ASP01ADD 1 2005 SP0126 pwdf2806 B1_2007BSP00 0 200727 pwdf2806 O5B12005ASP1ADD 1 2005 SP0128 pwdf2806 O5B12007BSP0 0 200729 pwdf2806 O5B12007BSP0ADD 1 200730 pwdf2807 B1_20042B 0 200431 pwdf2807 B1_2004A 0 200432 pwdf2807 B1_2004AADDON 1 200433 pwdf2807 B1_2005ASP00 0 2005 SP0034 pwdf2807 B1_2005ASP01 0 2005 SP0135 pwdf2807 B1_2005ASP01ADD 1 2005 SP0136 pwdf2807 B1_2007AFP01 0 2007 FP0137 pwdf2807 O5B12005ASP1 0 2005 SP0138 pwdf2807 O5B12005ASP1ADD 1 2005 SP0139 pwdf2807 O5B12007AFP01 0 2007 FP01

91

F. Elenco dei server gestiti 92

40 pwdf3119 B1_2004AADDON 1 200441 pwdf3119 B1_2005ASP00 0 2005 SP0042 pwdf3119 B1_2005ASP01 0 2005 SP0143 pwdf3119 B1_2005BSP00 0 2005 SP0044 pwdf3119 O5B12005ASP1 0 2005 SP0145 pwdf3119 O5B12005BSP0 0 2005 SP0046 pwdf3129 B1_2004A 0 200447 pwdf3129 B1_2004C 0 200448 pwdf3129 B1_2005ASP00ADD 1 2005 SP0049 pwdf3129 B1_2005ASP01 0 2005 SP0150 pwdf3129 B1_2005BSP00 0 2005 SP0051 pwdf3129 B1_2005BSP00ADD 1 2005 SP0052 pwdf3129 O5B12005ASP1 0 2005 SP0153 pwdf3129 O5B12005BSP0 0 2005 SP0054 pwdf3129 O5B12007ASP0 0 200755 pwdf3130 B1_2004AADDON 1 200456 pwdf3130 B1_2005ASP00 0 2005 SP0057 pwdf3130 B1_2005ASP01 0 2005 SP0158 pwdf3130 B1_2005BSP00 0 2005 SP0059 pwdf3130 O5B12005ASP1 0 2005 SP0160 pwdf3130 O5B12005BSP0 0 2005 SP0061 pwdf6003 B1_2005ASP01 0 2005 SP0162 pwdf6003 B1_2005ASP01ADD 1 2005 SP0163 pwdf6003 B1_2007ASP00 0 200764 pwdf6003 O5B12005ASP1 0 2005 SP0165 pwdf6003 O5B12005ASP1ADD 1 2005 SP0166 pwdf6003 O5B12007ASP0 0 200767 PWDF6500VM04 B1_2005ASP01 0 2005 SP0168 PWDF6500VM04 B1_2005BSP00 0 2005 SP0069 PWDF6500VM04 B1_2007ASP00 0 200770 PWDF6500VM04 O5B12005ASP1 0 2005 SP0171 PWDF6500VM04 O5B12005BSP0 0 2005 SP0072 PWDF6500VM04 O5B12007ASP0 0 200773 pwdf6544 B1_2005ASP01 0 2005 SP0174 pwdf6544 B1_2005BSP00 0 2005 SP0075 pwdf6544 B1_2007ASP00 0 200776 pwdf6544 O5B12005ASP1 0 2005 SP0177 pwdf6544 O5B12005BSP0 0 2005 SP0078 pwdf6544 O5B12007ASP0 0 200779 pwdf6545 B1_2005ASP01 0 2005 SP0180 pwdf6545 B1_2005BSP00 0 2005 SP0081 pwdf6545 B1_2007AFP01 0 2007 FP0182 pwdf6545 B1_2007ASP00 0 200783 pwdf6545 O5B12005ASP1 0 2005 SP0184 pwdf6545 O5B12005BSP0 0 2005 SP0085 pwdf6545 O5B12007AFP01 0 2007 FP0186 pwdf6545 O5B12007AFP01ADD 1 2007 FP0187 pwdf6545 O5B12007ASP0 0 200788 pwdfe025 B1_2005ASP00 0 2005 SP0089 pwdfe025 B1_2005ASP01 0 2005 SP0190 pwdfe025 B1_2005BSP00 0 2005 SP0091 pwdfe025 B1_2007ASP00 0 200792 pwdfe025 O5B12005ASP1 0 2005 SP0193 pwdfe025 O5B12005BSP0 0 2005 SP0094 pwdfe025 O5B12007ASP0 0 200795 pwdfe025 O5B12007ASP0ADD 1 2007

Bibliografia

[1] SAP AG. Database tables reference 2005a sp1. REFDB_2005, 2005.[cited at p. 1]

[2] SAP AG. Tec test environment center. TEC_Overview, 2007.[cited at p. 6]

[3] SAP AG. Sap business one system requirements v3.0.SBO_SystemRequirements, 2009. [cited at p. 5]

[4] Edgar F. Codd. Is your dbms really relational? ComputerWorld,1985. [cited at p. 50]

[5] Microsoft Corporation. Understan-ding and managing transaction logs.http:// technet.microsoft.com/en-us/ library/ms345583(SQL.90).aspx,2005. [cited at p. 26]

[6] Microsoft Corporation. User schema separation.http://msdn.microsoft.com/en-us/ library/ms190387(SQL.90).aspx,2005. [cited at p. 17]

[7] Microsoft Corporation. Set transaction isolation level (transact-sql).http://msdn.microsoft.com/en-us/ library/ms173763(SQL.90).aspx,2006. [cited at p. 48]

[8] Microsoft Corporation. sp_spaceused (transact-sql).http://msdn.microsoft.com/en-us/ library/ms188776(SQL.90).aspx,2008. [cited at p. 57]

[9] Microsoft Corporation. Designing indexed views.http://msdn.microsoft.com/en-us/ library/ms187864.aspx, 2009.[cited at p. 44]

93

BIBLIOGRAFIA 94

[10] Microsoft Corporation. sp_dboption.http://msdn.microsoft.com/en-us/ library/aa933268(SQL.80).aspx,2009. [cited at p. 58]

[11] Microsoft Corporation. Threads and threading.http://msdn.microsoft.com/en-us/ library/6kac2kdh(VS.80).aspx,2009. [cited at p. 34]

[12] Peter Fenwick and Simon Brierley. Compression of unicode files.Data Compression Conference, 1998. DCC ’98. Proceedings, 1998.[cited at p. 12]

[13] Mike Gunderloy and Joseph L. Jorden. Mastering SQLServer 2000.Sybex, 2000. [cited at p. 57]

[14] Citrix Systems Inc. Citrix metaframe application ser-ver for windows 2000 servers - administrator’s guide.http:// support.citrix.com/servlet/KbServlet/download/2171-102-8281/MF18EN.pdf ,2000. [cited at p. 6]

[15] VMware Inc. Vmware server2 datasheet.http://www.vmware.com/files/pdf/ server_datasheet.pdf , 2009.[cited at p. 8]

[16] Davide Mauri. Sequel server 2005 overview. Solid Quality LearningArticle, 2007. [cited at p. vii, 47]

[17] Ingo Rammer and Mario Szpuszta. Advanced .NET Remoting.Apress, 2 edition, 2005. [cited at p. 12, 36]

[18] Mathes e altri Schwarzkopf. Java rmi versus .net remoting - architec-tural comparison and performance evaluation. Seventh InternationalConference on Networking, 2008. [cited at p. 12]

[19] Eindhoven University Of Technology. Sequoiaview.http://w3.win.tue.nl/nl/onderzoek/onderzoek_informatica/visualization/ sequoiaview// ,2002. [cited at p. 26]

[20] Kimberly L. Tripp. Partitioned tables and indexes in sql ser-ver 2005. http://msdn.microsoft.com/en-us/ library/ms345146.aspx,2005. [cited at p. 46]

Acronimi

SAP Systeme Anwendungen Produkte in der Datenverarbeitung

GSC SAP Global Support Center

TEC Test Environment Center

IBD Install Base Development

B1 SAP Business One

SSP Software Solution Partner

IVU Inventory Valuation Utility

USD Upgrade Solution Desk

SBO-COMMON SAP Business One Common Database

FUP Forced Upgrade Process

SFTP Secure File Transfer Protocol

GTL Gobal Topic Lead

B1 Business One

SBO-BC Business Core

SBO-BC-UPG Upgrade

SBO-BC-ADD AddOn

ERP Enterprise Resource Planning

CSN Customer Support System New

PL Patch Level

MS Microsoft

95

F. Acronimi 96

MS SSMS Microsoft Sql Server Management Studio

DB2 IBM Database2 DBMS

DBMS Database management system

VPN Virtual Private Network

TCP Transmission Control Protocol

HTTP Hypertext Transfer Protocol

UDT User Defined Table

UDF User Defined Field

SAO Server Activated Object

CAO Client Activated Object

OLAP Online Analytical Processing

TEC Admin TEC System Administrator

Tesi_Manfrin

Documents

Transcript of Tesi_Manfrin