Re: Change database character set
Date: Fri, 24 Oct 2014 08:32:55 -0400
Message-ID: <CAEidWqP3H3EAg=_FFmcDN47WLmi8xxXm84BWv3jWUtE0kAAJHg_at_mail.gmail.com>
I don't believe that worked for us.
On Oct 24, 2014 8:30 AM, "Niall Litchfield" <niall.litchfield_at_gmail.com> wrote:
> You can verify the Agent issue by stopping it (or dbconsole) and re running
> On 24 Oct 2014 13:10, "Kenny Payton" <k3nnyp_at_gmail.com> wrote:
>
>> It sounds like you're getting off easy. As for the sys.reg$ row we had a
>> similar row and it was related to the emagent. We probably could have got
>> away with just deleting it but what we did was create a table in a user
>> schema with the row in it, export the user table, delete the row from both
>> tables and then reload the row after the csalter. In hindsight this
>> probably wasn't necessary but worked.
>>
>> You could probably do the same with the clob data as well.
>>
>>
>>
>>
>> On Fri, Oct 24, 2014 at 8:04 AM, Scott Canaan <srcdco_at_rit.edu> wrote:
>>
>>> Actually, I’ve been considering doing something similar to this. The
>>> 9 rows in that table (out of about 20) that are affected were added in
>>> August and the person that added them still has the original documents, so
>>> they could be reloaded after the conversion. I believe that what is in the
>>> HUGECLOB in that table is just a word document that was cut and pasted into
>>> the field.
>>>
>>>
>>>
>>> The only row that really concerns me is the one in SYS.REG$.
>>>
>>>
>>>
>>> Scott Canaan ’88 (srcdco_at_rit.edu)
>>>
>>> (585) 475-7886 – work (585) 339-8659 – cell
>>>
>>> “Life is like a sewer, what you get out of it depends on what you put
>>> into it.” – Tom Lehrer
>>>
>>>
>>>
>>> *From:* Chris Taylor [mailto:christopherdtaylor1994_at_gmail.com]
>>> *Sent:* Friday, October 24, 2014 8:01 AM
>>> *To:* Niall Litchfield
>>> *Cc:* Scott Canaan; oracle.unknowns_at_gmail.com; oracle-l_at_freelists.org
>>> *Subject:* Re: Change database character set
>>>
>>>
>>>
>>> Based on Niall's analysis, another option could be to export the
>>> SCRIPT_GROUP table, truncate it, do the conversion and reload it (depending
>>> on the size).
>>>
>>>
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Oct 24, 2014 at 5:02 AM, Niall Litchfield <
>>> niall.litchfield_at_gmail.com> wrote:
>>>
>>> Scott
>>>
>>>
>>>
>>> I'm pretty sure you'll find the session_key row is transient and due to
>>> an emagent (either grid/cloud control or dbconsole) - there's a note on
>>> csscan dictionary errors that will tell you. That leaves you with 9
>>> documents (they look like word docs/emails). Can you grab those from the
>>> app and reenter the data post conversion?
>>>
>>>
>>>
>>
>>
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Oct 24 2014 - 14:32:55 CEST