Re: RE: convert big endian to medium endian

Hi
The problem the source and target should share the same endian format. In my case the source is big endian and the target is little endian. Therefore the idea to convert the datafiles outside the db to the right endian format. But I don't know whether that is possible.

Thanks and regards
Ahmed

Ls Cheng <exriscer_at_gmail.com> schrieb am Sa., 8. Feb. 2020, 09:52:

> ops forget that, you have different endian
>
> can you consider GoldenGate?
>
> On Sat, Feb 8, 2020 at 9:51 AM Ls Cheng <exriscer_at_gmail.com> wrote:
>
>> have a look TRANSPORTABLE DATABASE (rman convert database)
>>
>>
>> https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmxplat.htm#BRADV89988
>>
>>
>>
>> https://docs.oracle.com/en/cloud/cloud-at-customer/exadata-cloud-at-customer/exacc/mig-transportable-database.html#GUID-4C757BA1-0C1D-498A-B5F7-7F4738243301
>>
>>
>>
>>
>> On Fri, Feb 7, 2020 at 11:35 PM Ahmed Fikri <gherrami_at_gmail.com> wrote:
>>
>>> I agree with this wise advise. And I'm sure we will opt for the safe
>>> method. But my question is now only to have better understanding for how
>>> oracle works.
>>>
>>> I suppose now that I have only 10 GB Database it is possible to migrate
>>> it to a different endian without using XTTS?
>>>
>>> Best regards
>>>
>>>
>>> Sweetser, Joe <JSweetser_at_icat.com> schrieb am Fr., 7. Feb. 2020, 23:21:
>>>
>>>> Being possible and being supported are 2 different things. With a
>>>> database that size, I would tend to stay in a supported universe.
>>>>
>>>>
>>>>
>>>> -joe
>>>>
>>>>
>>>>
>>>> *From:* oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> *On
>>>> Behalf Of *Ahmed Fikri
>>>> *Sent:* Friday, February 7, 2020 3:03 PM
>>>> *To:* ORACLE-L <oracle-l_at_freelists.org>
>>>> *Subject:* Re: RE: convert big endian to medium endian
>>>>
>>>>
>>>>
>>>> sorry to ask again to this topic: why it is not possible to take all
>>>> datafiles from the aix with big endian and convert them using external
>>>> program (maybe a c program or even a dbms_file_transf r from other oracle
>>>> instance) to the target endian and use them to create the new DB? This is
>>>> like creating a new Database using a cold backup only with the additional
>>>> step to convert the datafiles. I'm unfortunately not convinced that we
>>>> should use the TTS methode. I think that using TTS is only good if we want
>>>> to copy only a few TS of the DB. But in my case I want to copy the whole DB.
>>>>
>>>>
>>>>
>>>> Thanks and regards.
>>>>
>>>>
>>>>
>>>>
>>>> Am Fr., 7. Feb. 2020 um 20:41 Uhr schrieb Ahmed Fikri <
>>>> gherrami_at_gmail.com>:
>>>>
>>>> Only some additional information about the source DB:
>>>>
>>>> The db has about 4 million table/index partitions and every days will
>>>> be created about 1 Thousand Partitions (I'm not sure whether this is good
>>>> design). This could be maybe the reason why the metadata export is so
>>>> slowly.
>>>>
>>>>
>>>>
>>>> And to be honest the DBAs have already given some mos id for the
>>>> datapump issue concerning the 11.2.0.4 version related to some x$k.. view.
>>>> (I can't remember that now and I have now no access to my work email)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Ahmed Fikri <gherrami_at_gmail.com> schrieb am Fr., 7. Feb. 2020, 19:26:
>>>>
>>>> I write this email from an other email box(I'm in the train and the
>>>> other app doesn't work now)
>>>>
>>>>
>>>>
>>>> Thanks a lot Lewis not only for your technical explanation but also for
>>>> reading between the lines and understanding my real problem. (Even my
>>>> broken English)
>>>>
>>>>
>>>>
>>>> Thanks and Regards
>>>>
>>>> Ahmed
>>>>
>>>>
>>>>
>>>> Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk> schrieb am Fr., 7. Feb.
>>>> 2020, 19:15:
>>>>
>>>>
>>>> Your approach will not work because Oracle Corp. has not implemented an
>>>> "in situ" mechanism for reading and updating a system tablespace and data
>>>> dictionary that is in the wrong endian format. If they had produced such a
>>>> mechanism they would have been shouting about it because it would make it
>>>> much easier to migrate to Exadata from any alien platform.
>>>>
>>>> If your dba is an expert then they might have mentioned which version
>>>> of Oracle (11g is not a version, it's a marketing term), and which bug.
>>>> There are many known bugs relating to slow metadata export and many of
>>>> those bugs have patches. If your dba is a really expert expert they may
>>>> even be able to work out WHY the export is slow (if there isn't a patch to
>>>> fix their problem) and hack the data dictionary or supply SQL Patches to
>>>> speed it up.
>>>>
>>>>
>>>> Regards
>>>> Jonathan Lewis
>>>>
>>>> ________________________________________
>>>> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on
>>>> behalf of ahmed.fikri_at_t-online.de <ahmed.fikri_at_t-online.de>
>>>> Sent: 07 February 2020 17:16
>>>> To: Clay.Jackson_at_quest.com
>>>> Cc: oracle list
>>>> Subject: AW: RE: convert big endian to medium endian
>>>>
>>>> thanks for this information. But when I hear the only one way to do
>>>> something, I need to know why there is only one way. And why my approach
>>>> will not work.
>>>>
>>>> My problem is when using XTTS I should (from my understanding) export
>>>> the metadata using datapump and the problem this takes 3 days and 4 hours.
>>>> And from my understanding why should I export the metadata. Our DBA is an
>>>> expert and he told me the export takes long time because of known bug in
>>>> 11g. In the past I could copy databases using only cold backup, I could
>>>> copy the data files in parallel using several processes. I'm not a DBA (I
>>>> am from the application vendor installed on the db) but I read D. Kuhn book
>>>> from the beginning to the end. So I need to understand how to to do this
>>>> task: upgrading 11g on aix to 12g on linux in less than one weekend without
>>>> using the buggy datapump.
>>>>
>>>> this should be possible or not?The db is only 16tb big.
>>>>
>>>> regards
>>>> Ahmed
>>>>
>>>>
>>>>
>>>>
>>>> Gesendet mit der Telekom Mail App
>>>>
>>>>
>>>>
>>>> --- Original-Nachricht ---
>>>> Von: Clay Jackson (cjackson)
>>>> Betreff: RE: convert big endian to medium endian
>>>> Datum: 07.02.2020, 17:55 Uhr
>>>> An: oracle list
>>>>
>>>>
>>>> AFAIK:
>>>>
>>>> The only way this would work would be with transportable tablespaces;
>>>> either using the tablespaces, or RMAN (MOS 2013271.1).
>>>>
>>>> There’s no “silver bullet” for this…
>>>>
>>>>
>>>>
>>>> IMHO, your best choice is export/import with some sort of replication
>>>> solution to help minimize downtime.
>>>>
>>>>
>>>>
>>>> Clay Jackson
>>>>
>>>> Database Solutions Sales Engineer
>>>>
>>>> clay.jackson_at_quest.com
>>>>
>>>> office 949-754-1203 mobile 425-802-9603
>>>>
>>>> 
>>>>
>>>>
>>>>
>>>> From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> On
>>>> Behalf Of ahmed.fikri_at_t-online.de
>>>> Sent: Friday, February 7, 2020 6:02 AM
>>>> To: oracle list <oracle-l_at_freelists.org>
>>>> Subject: convert big endian to medium endian
>>>>
>>>>
>>>>
>>>> CAUTION: This email originated from outside of the organization. Do not
>>>> follow guidance, click links, or open attachments unless you recognize the
>>>> sender and know the content is safe.
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I want to test (I hope this weekend) following:
>>>> 1 from 12c Db on AIX (big endian) I will create a cold backup
>>>> 2 on Oracle linux (medium endian) I will create a new db using the cold
>>>> backup from point 1
>>>> 3 somehow I should convert the files from point 1 in medium endian
>>>>
>>>> is this possible?
>>>>
>>>> I don't want to use XTTTS and exporting the metadata using data pump.
>>>>
>>>> Kind Regards
>>>> Ahmed
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Gesendet mit der Telekom Mail App
>>>>
>>>> This e-mail transmission and any attachments that accompany it may
>>>> contain information that is privileged, confidential or otherwise exempt
>>>> from disclosure under applicable law and is intended solely for the use of
>>>> the individual's to whom it was intended to be addressed. If you have
>>>> received this e-mail by mistake, or you are not the intended recipient, any
>>>> disclosure, dissemination, distribution, copying or other use or retention
>>>> of this communication or its substance is prohibited. If you have received
>>>> this communication in error, please immediately reply to the author via
>>>> e-mail that you received this message by mistake and also permanently
>>>> delete the original and all copies of this e-mail and any attachments from
>>>> your computer. Please note that coverage cannot be bound or altered by
>>>> sending an email. You must receive written confirmation from a
>>>> representative of our firm to put coverage in force or make changes to an
>>>> existing policy.
>>>>
>>>

--
http://www.freelists.org/webpage/oracle-l