Fwd: RE: convert big endian to medium endian

• Forwarded message --------- Von: Ahmed Fikri <gherrami_at_gmail.com> Date: Sa., 8. Feb. 2020, 10:56 Subject: Re: RE: convert big endian to medium endian To: Ls Cheng <exriscer_at_gmail.com>

We are also investigating goldengate possibly. But now just for my understanding I want to find a way to do that without rman. Only with the old things datafiles, linux, etc

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