Articolo originale pubblicato giovedì 25 agosto 2011

Mi chiamo Anthony Cafarelli e in qualità di Consultant presso Microsoft Consulting Services ho recentemente compilato un elenco di suggerimenti utili che ho raccolto durante lo svolgimento di analisi OMPM presso le sedi dei clienti. In questo post di blog vorrei condividere parte di quell'esperienza e spero che chiunque lo legga possa trovarlo utile.

L'aspetto che intendo affrontare in questo post di blog riguarda un errore di importazione che si verifica quando i file analizzati presentano nomi molto lunghi, contenenti più di 250 caratteri. Si tratta pertanto di un errore non molto comune, tuttavia questa procedura vi aiuterà a completare l'importazione qualora vi trovaste in questa situazione. Durante l'importazione di dati nel database OMPM è possibile che riscontriate l'errore seguente:

Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data

Questo errore indica che il nome del file e il percorso in un file XML che state tentando di importare è troppo lungo per il campo “Warninginfo” nella tabella osWarning. Poiché si tratta di un problema di lunghezza, le informazioni non vengono importate nel database e il file XML viene saltato. In genere questo risulta evidente nell'avviso Ultimo accesso o Data ultima modifica, pertanto l'assenza di questi file nel database normalmente non comporta alcun problema. Se tuttavia il file fa parte di un file CAB contenente più file XML (cosa molto probabile e spesso il file CAB contiene 10.000 file, a meno che non abbiate modificato il file offscan.ini per cambiare tali impostazioni) è importante notare che la mancata importazione di uno qualsiasi dei file XML contenuti in un file CAB impedisce l'importazione di tutti gli altri file nel database. A questo punto avete alcune opzioni:

1)      Ignorare che il file CAB non è stato importato e basare i risultati su altri file CAB/XML importati correttamente.

2)      Estrarre il file CAB e importare ogni file XML.

3)      Modificare il database.

Se l'opzione 1 è accettabile, il problema è risolto. È l'opzione più facile, ma se perdete una notevole quantità di dati, potrebbe risultare utile.

L'opzione 2 è interessante e, tra le 2 che ho elencato per risolvere questo problema, è quella che implica un notevole lavoro da parte dei tecnici e aumenta significativamente il tempo di importazione nel database.

Vi fornisco alcune informazioni di riferimento in maniera semplificata: il motivo per cui l'intero file CAB non viene importato se un solo file XML presenta un errore è dovuto al modo in cui OMPM esegue l'importazione. Il file CAB viene estratto dal processo di importazione e tutti i file XML vengono analizzati contemporaneamente. Questa modalità velocizza in modo considerevole l'importazione di un file CAB ma riduce anche la possibilità di far fronte agli errori.

Se estraete i file XML sarete in grado di ottenere in media gli altri 9.999 file XML importati nel database. Non ho effettivamente confrontato i volumi e i tempi, ma direi che l'importazione di singoli file XML è almeno 10 volte più lenta. Esiste un altro modo per incrementare la velocità di importazione, ma richiede più lavoro da parte dei tecnici. È il mio metodo preferito perché odio modificare il database per problemi di supportabilità e lo descriverò in maggior dettaglio in seguito. Questa è l'opzione 2 modificata:

1)      Estraete il file CAB.

2)      Utilizzate il comando findstr per individuare il file XML estratto che presenta l'errore.

3)      Eliminate tale file XML.

4)      Ricomponete il file CAB con i file restanti.

Con questo metodo potete mantenere un'elevata velocità di importazione e risolvere il problema del file con il nome lungo. L'uso del comando findstr e l'eliminazione del file XML sono operazioni semplici, pertanto non le approfondirò. Tuttavia ricomporre correttamente il file CAB può rivelarsi un compito insidioso. Il mio consiglio è di visitare la pagina seguente di TechNet e implementare gli script PowerShell elencati:

http://technet.microsoft.com/en-us/magazine/2009.04.heyscriptingguy.aspx?pr=blog

Dopo aver ricompresso i file in un altro file CAB, potete importarlo e mantenere un'elevata velocità di importazione. Niente male, che ne dite?

Ora esaminiamo l'opzione 3, di cui non ho un'opinione ben definita. È semplice ed efficace, ma mette a rischio la supportabilità. Questo approccio può essere spiegato semplicemente: il campo oswarning nel database non è sufficientemente grande da contenere i dati che intendiamo inserirvi, quindi dobbiamo ingrandirlo. Ho trovato i seguenti 2 metodi che assolvono allo scopo:

1)      Utilizzate SQL Management Studio per modificare le dimensioni del campo.

2)      Modificate i file utilizzati da OMPM per creare il database in modo che tutti i database creati da quel momento avranno direttamente dimensioni maggiori per il campo.

Utilizzare SQL Management Studio è semplice, ma può risultare leggermente diverso a seconda della versione di SQL che adoperate. Non ho intenzione di approfondire questa soluzione, pertanto se avete dei dubbi in merito potete consultare la vostra risorsa SQL preferita (amici, colleghi, documenti, blog e così via) oppure utilizzare il secondo metodo. 

Il secondo metodo richiede l'uso di un editor di testo. Notepad.exe è il mio preferito, pertanto lo utilizzerò come esempio. Avviate Blocco note e aprite ProvisionDB.sql nella cartella OMPM/Database/Include.

Dopo aver aperto il file, cercate “oswarning” e fate clic su Trova successivo.

Verrà visualizzato quanto segue:

Questo è il campo WarningInfo (con un massimo di 255 caratteri). Aumentate semplicemente il numero, ad esempio a 285, e salvate il file. A questo punto, ogni volta che eseguite il comando createdb, il nuovo database disporrà di un campo più grande. NOTA: questa procedura non modifica i database esistenti, pertanto create un nuovo database per eseguirvi le importazioni. Estraete qualsiasi file dalla cartella OMPMimported che avete importato nel database precedente in modo da ripetere l'importazione nel nuovo database.

Il team di Office Compatibility è a conoscenza di questa limitazione e sta considerando l'aspetto per aggiornamenti futuri.

Spero che questo articolo sia stato di aiuto. Ho intenzione di scrivere altri post di blog su altri problemi e soluzioni “creative” che ho scoperto sul campo.

Anthony

Questo è un post di blog localizzato. L'articolo originale è disponibile in Experience from the Field: Resolving the OMPM issue “Type of column ‘WarningInfo’ in table ‘osWarning’ is too small to hold data”