Oracle Globalization Support – Parte II

lunedì 14 luglio 2008 alle 14:03 | Pubblicato su Installation and Configuration, Oracle Certification | 3 commenti
Tag: , ,

La disponibilità scarsa di frammenti di tempo “libero” che superino la mezz’ora mi porta talvolta a fare dei post frettolosi, come è accaduto per il precedente. D’altra parte se non l’avessi fatto così in fretta probabilmente avrei finito per non farlo affatto.

Prima di proseguire con la panoramica di quello che oracle chiama “Globalization Support” (intendento ciò che è stato fatto per supportare linguaggi, costumi del mondo a livello di database), farò un piccolo riassunto della puntata precedente.

Un primo elemento di supporto alla globalizzazione che un DBMS deve avere è il supporto a più character set. Questo supporto serve per gestire la memorizzazione delle stringhe, del testo, per i numeri e le date non è rilante. Come ho già detto, agli albori dell’informatica moderna un charset a 7 bit come ASCII era sufficente a coprire gran parte degli utilizzi. Un suo “concorrente” fu EBCDIC forse meno noto. Con l’evolversi ed il diffondersi dell’utilizzo dei sistemi informatici i charset sono proliferati per coprire tutte le esigenze, riporto un paio di esempi,  http://www.columbia.edu/kermit/csettables.html dove sono riportate alcune tabelle, ma poi non manca la puntuale informazione della wikipedia, con la voce “Character encoding” e “Code Page“. Ad un certo punto si deciso di fare uno standard globale anche in questo campo ed è nato UNICODE (wikipedia) che ha creato UTF-8. Nel post precedente, basandomi sulla guida Oracle ho affermato che UFT-8 è arrivato alla versione 4.0, in realtà dalla wikipedia apprendo che la versione 4.0 risale all’ormai lontano 2003 e che ad oggi siamo alla 5.1 (abbastanza recente, pare aprile 2008).

Sempre nel post precedente parlando del problema che nasce dalle differenze di charset tra client e server ho fatto l’esempio dell macchina con cui lavoro, su cui è installato l’onnipresente winzoz che si presenta con una code page 850. Questa tabella include in realtà i caratteri usati nei cosiddetti paesi dell’Europa dell’Ovest. E’ un sopra insieme del charset ISO-8859-1 , così pare almeno affermare wikipedia. Essendo però entrambi charset ad un byte desumo, senza mettermi a fare il confronto che coprano lo stesso insieme di caratteri ma che usino una codifica diversa. Invece sempre wikipedia mi conferma che la code page 65001 è equivalente a UTF-8, tant’è che la pagina viene rimandata a quella di UTF-8.

Direi che tutti i riferimenti che ho citato sono sufficenti per chi volesse approfondire ulteriormente i dettagli sui charset.

Tornando al tema principale ricordo che le informazioni dettagliate sul supporto alla globalizzazione nel database oracle sono raccolte in un manuale dedicato a ciò intitolato proprio “Oracle Database Globalization Support Guide” (per 11g e qui). Di questo manuale è il caso di leggere attentamente il capitolo 5, initolato “Linguistic Sorting and String Searching” (per 11g è qui). Il capitolo è importante perchè spiega in sostanza l’utilizzo, il significato ed il settaggio dei due parametri NLS_SORT e NLS_COMP. Essi influiscono rispettivamente sul come vengono fatti gli ordinamenti delle stringhe e su come vengono fatti i confronti. Per default essi hanno entrambi il valore “binary” il che significa che l’ordinamento e il confronto delle stringhe è basato esclusivamente sulla loro codifica numerica (quindi in qualche modo dipende dal charset).

Tempo fa ho affrontato il tema delle ricerche “case insensitive” in oracle (qui e qui) , ovvero le ricerche su stringhe senza distinzione tra maiuscole e minuscole. Come ebbi modo di constatare non c’era modo di fare ricerche case insensitive con il LIKE utilizzando indici. Ebbene segnalo che su 11g invece è possibile. Infatti nel manuale, prima di questo paragrafo è cambiato la nota che prima diceva:

Note:

The SQL functions MAX( ) and MIN( ), and also the LIKE operator, cannot use linguistic indexes when NLS_COMP is set to LINGUISTIC

Che smentiva quanto diceva prima il manule, ora dice:

Note:

The SQL functions MAX( ) and MIN( ) cannot use linguistic indexes when NLS_COMP is set to LINGUISTIC.

Ed  in effetti ho fatto una prova e funziona, provare per credere.

Fino alla 10g essenzialmente i cosiddetti indici linguistici (“Linguistic Index”) servono solo per ricerche per uguaglianza e per ordinamenti.

In ogni caso, come è possibile apprendere dal manuale, sempre dal capitolo 5, oracle prevede una infrastruttura abbastanza sofisticata per gestire i vari metodi di ordinamento in uso in alcune regioni del mondo. Questa infrastruttura è implementata tramit la “Oracle NLS Runtime Library (NLSRTL). Tramite uno strumento chiamato “Oracle Locale Builder” è possibile definire delle personalizzazioni.

Per concludere ricordo le viste di sistema per controllare i settaggi “NLS”:

Sono sicuramente stato superficiale ed incompleto in questa descrizione del Supporto alla Globalizzazione nei database Oracle (Oracle Database Globalization Support) ma non poteva essere altrimenti. Per gli approfondimenti rimando al manuale ed alla pratica.

P.S. (15/07/2008)

Ieri volevo aggiungere anche un ulteriore riferimento, questo thread di discussione su CDOS in cui c’è anche un intervento di Jonathan Lewis che rimanda a due post di Richard Foote, il guru degli indici in Oracle🙂.

3 commenti »

RSS feed for comments on this post. TrackBack URI

  1. Ciao, ho un grosso problema con un caso di ordinamento.
    Ho un db Oracle 10g su un server 2008 in inglese, ed una semplice query che imposta un “order by” su una colonna nvarchar; il risultato è mostrato in una pagina aspx.
    Il mio grosso problema è che se richiedo la pagina aspx, interrogando il db dalla mia macchina i risultati mi ritornano come me li aspetto, ovvero in case-insenstivie.
    Se invece navigo il sito direttamente sul server, in quella pagina i risultati sono mostrati come se la query ritornasse i valori ordinati in maniera case-sensitive.

    Capito? Stessa query, stesso sito, ma risultati diversi.
    Ciò che cambia è il sistema operativo sul quale gira IIS, nel mio caso un Vista 64bit in italiano.

    Segnalo che eseguendo la query su SqlDeveloper, i risultati sono case-insensitive.

    Non è servito neppure impostare i parametri NLS_SORT e NLS_COMP attraverso questo script
    alter system set NLS_SORT = binary_ci scope = spfile
    alter system set NLS_COMP = ‘LINGUISTIC’ scope = spfile

    Cosa può essere?
    Sto impazzendo.
    Marco

    • Credo sia sbagliato modificare i parametri a livello di sistema, prova a farlo a livello di sessione (e quindi di client):
      alter session set nls_sort=binary_ci;
      alter session set nls_comp=’LINGUISTIC’;

  2. […] un paio di post alla gestione della “globalizzazione” in Oracle, i post sono questo  e questo. Ad oggi ogni tanto ancora incontro problemi nella gestione sul database di caratteri particolari […]


Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Crea un sito o un blog gratuitamente presso WordPress.com.
Entries e commenti feeds.

%d blogger cliccano Mi Piace per questo: