Re: DB character set
In case anybody is interested in the character set business: I asked this question (best char set for mixed environment of Unix and MS DBs with primarily MS clients and C/S applications) Gilles Briard, the author of article in OraMag on accomodating Euro symbol in a DB (http://www.oracle.com/oramag/webcolumns/2001/index.html?euro.html). After couple of emails I realized that the basic question I should've asked in the first place is much simpler: Q: If DB charater set is WE8ISO8859P1 1-st user on MS Win with client side char set (part of NLS_LANG) WE8MSWIN1252 2-nd user on Unix with client side char set WE8ISO8859P1 Would there be any difference in performance (elapsed time) if both clients (one on Unix, one on MS Win) are located on the same segment with the same network bandwith and latency and run the same simple query (say select * from sys.source$; in SQL* Plus) ? I always thought that the one on MS Win might be slower (in the example above) because Oracle has to go through a char set conversion. The following URL from Oracle Globalization Guide seemed to confirm that: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/ch2.htm#100796 Gilles response was that if all other factors are the same and the only difference is the NLS_LANG value on the client, than user on Unix and MS should expirience the same performance (if I understood it correctly). The reason for this is the following steps that Oracle goes through in any case: 1 - DB server: translate char set P15 data to binary 2 - network transmission of binary data 3 - Client: translate binary to P15 back (in case of Unix) OR to WIN1252 (in case of MS Win) 4 - Client: graphical transformation So translation in step 3 or translation with conversion (or is it conversion with translation?) cost the same? I'll be setting up a test maybe next week (not only for performance impications, but also to check if symbols like 1/2 and 1/4 we use here can be stored and retrieved back), but I would appreciate if anybody can comment on the above. Resources used - 1. Globalization Guide 2. 144192.1 Whether or not to change the DB char set to support the Euro sign 3. 225938.1 Do I have incorrect char in the DB and how to recover 4. 140014.1 RDBMS support for the Euro Currency symbol 5. 15095.1 Exp/Imp and NLS considerations 6. 119119.1 UTF8 DB char set implications 7. 181508.1 Choosing the DB char set 8. 137127.1 Char set, Code Pages, Fonts and the NLS_LANG value 9. 158577.1 NLS_LANG explained (how does client-server char converison works?) 10. http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/ch2.htm#100796 Thanks, Boris Dali. --- Boris Dali [EMAIL PROTECTED] wrote: Dear List, Life was pretty easy here before they came up with this euro symbol :-( We had WE8ISO8859P1 (the default I bevieve) as a char set on all Unix and MS (sorry we have those as well) DBs accross the board. That was also the client side char set (part of NLS_LANG) - most clients here are on MS (code page 1252), some browser based. Well, with euro it looks like they went different directions: - On MS: it's recommended to have WE8MSWIN1252 (super set of good old WE8ISO8859P1) - On Unix: it's WE8ISO8859P15 My question is: 1. if I want to stick with one char set accross the board (as we have now) for all DBs on Unix and MS AND 2. avoid (automatic, but not free) conversion on DB-Client Net communication AND 3. we need euro symbol is there a painless solution out there? Thanks, Boris Dali __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line
RE: DB character set
We have been dealing with the same issues here. That is great information. Thanks! Todd Carlson Oracle Database Administrator Tripos, Inc. (314) 647-8837 Ext.3246 -Original Message- Sent: Tuesday, February 18, 2003 11:11 AM To: Multiple recipients of list ORACLE-L In case anybody is interested in the character set business: I asked this question (best char set for mixed environment of Unix and MS DBs with primarily MS clients and C/S applications) Gilles Briard, the author of article in OraMag on accomodating Euro symbol in a DB (http://www.oracle.com/oramag/webcolumns/2001/index.html?euro.html). After couple of emails I realized that the basic question I should've asked in the first place is much simpler: Q: If DB charater set is WE8ISO8859P1 1-st user on MS Win with client side char set (part of NLS_LANG) WE8MSWIN1252 2-nd user on Unix with client side char set WE8ISO8859P1 Would there be any difference in performance (elapsed time) if both clients (one on Unix, one on MS Win) are located on the same segment with the same network bandwith and latency and run the same simple query (say select * from sys.source$; in SQL* Plus) ? I always thought that the one on MS Win might be slower (in the example above) because Oracle has to go through a char set conversion. The following URL from Oracle Globalization Guide seemed to confirm that: http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/ch2. htm#100796 Gilles response was that if all other factors are the same and the only difference is the NLS_LANG value on the client, than user on Unix and MS should expirience the same performance (if I understood it correctly). The reason for this is the following steps that Oracle goes through in any case: 1 - DB server: translate char set P15 data to binary 2 - network transmission of binary data 3 - Client: translate binary to P15 back (in case of Unix) OR to WIN1252 (in case of MS Win) 4 - Client: graphical transformation So translation in step 3 or translation with conversion (or is it conversion with translation?) cost the same? I'll be setting up a test maybe next week (not only for performance impications, but also to check if symbols like 1/2 and 1/4 we use here can be stored and retrieved back), but I would appreciate if anybody can comment on the above. Resources used - 1. Globalization Guide 2. 144192.1 Whether or not to change the DB char set to support the Euro sign 3. 225938.1 Do I have incorrect char in the DB and how to recover 4. 140014.1 RDBMS support for the Euro Currency symbol 5. 15095.1 Exp/Imp and NLS considerations 6. 119119.1 UTF8 DB char set implications 7. 181508.1 Choosing the DB char set 8. 137127.1 Char set, Code Pages, Fonts and the NLS_LANG value 9. 158577.1 NLS_LANG explained (how does client-server char converison works?) 10. http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96529/ch2. htm#100796 Thanks, Boris Dali. --- Boris Dali [EMAIL PROTECTED] wrote: Dear List, Life was pretty easy here before they came up with this euro symbol :-( We had WE8ISO8859P1 (the default I bevieve) as a char set on all Unix and MS (sorry we have those as well) DBs accross the board. That was also the client side char set (part of NLS_LANG) - most clients here are on MS (code page 1252), some browser based. Well, with euro it looks like they went different directions: - On MS: it's recommended to have WE8MSWIN1252 (super set of good old WE8ISO8859P1) - On Unix: it's WE8ISO8859P15 My question is: 1. if I want to stick with one char set accross the board (as we have now) for all DBs on Unix and MS AND 2. avoid (automatic, but not free) conversion on DB-Client Net communication AND 3. we need euro symbol is there a painless solution out there? Thanks, Boris Dali __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California--
RE: DB character set
Hrm, how about UTF8? -Original Message- Sent: Wednesday, February 05, 2003 4:20 PM To: Multiple recipients of list ORACLE-L Dear List, Life was pretty easy here before they came up with this euro symbol :-( We had WE8ISO8859P1 (the default I bevieve) as a char set on all Unix and MS (sorry we have those as well) DBs accross the board. That was also the client side char set (part of NLS_LANG) - most clients here are on MS (code page 1252), some browser based. Well, with euro it looks like they went different directions: - On MS: it's recommended to have WE8MSWIN1252 (super set of good old WE8ISO8859P1) - On Unix: it's WE8ISO8859P15 My question is: 1. if I want to stick with one char set accross the board (as we have now) for all DBs on Unix and MS AND 2. avoid (automatic, but not free) conversion on DB-Client Net communication AND 3. we need euro symbol is there a painless solution out there? Thanks, Boris Dali __ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Boris Dali INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Richard Ji INET: [EMAIL PROTECTED] Fat City Network Services-- 858-538-5051 http://www.fatcity.com San Diego, California-- Mailing list and web hosting services - To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
