Re: RE: convert big endian to medium endian

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