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        -- 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: Todd Carlson
  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).

Reply via email to