More on my Unicode conversion
- From: "Vergara, Michael (TEM)" <mvergara@xxxxxxxxxxx>
- To: "Oracle-L (E-mail)" <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 7 Sep 2004 11:44:22 -0700
Hi Everyone:
I should've provided more info. Our Unicode conversion was a
down-time conversion, using SAP's export/import tool called R3load.
I went from one physical database to another, from US7ASCII to
UTF8. We could not do a simple 'alter' because there were 8-bit
data stored in the DB, and moreover SAP makes much use of LONG RAW
data types.
There are no direct user connections to the DB. Users connect to
one of the app servers, and the app servers connect to the DB.
I have validated all of the app server environments to be=20
in accordance with the new system (specifically NLS_LANG and
ORA_NLS33).
We did just now hear from one of the ABAP programmers that there
is an issue with the program that's causing the most problems. It
seems they were using hints, and had hard-coded the index names
into the program. Well, as part of this conversion, SAP changed
the names of the indexes from (for example) "MSEG______0" to
"MSEG~0". So the hinted indexes did not exist, hence the dreaded
FTS - roughly ten to twelve of them, on a series of large (10-20G)
tables. Can you say 'hot blocks'?
However, now that those particular programs have been stopped and
are being fixed, we are still seeing the latch wait phenomena,=20
but at a reduced scale. So we still have the problem...
Thanks,
Mike
---
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Michael P. Vergara
Oracle DBA
Guidant Corporation
www.guidant.com <http://www.guidant.com/>
--
To unsubscribe - mailto:oracle-l-request@xxxxxxxxxxxxx&subject=unsubscribe
To search the archives - //www.freelists.org/archives/oracle-l/
Other related posts:
- » More on my Unicode conversion
