XPRA to minimize downtime durina upgrade

Hello Experts,
I am looking for information about XPRAs and system downtime during upgrade. Is it possible to modify XPRAs that has to be run during upgrade inorder to reduce the downtime, how? Please provide me other suggestions in order to reduce the downtime with XPRAs...
Thanks...
Viral

Hi Viral,
When you will run the prepare it will give you how many xpra objects are there for conversion.You can work on the xpra objects at uptime period.
Regarding parallel process when you will run the upgrade it will ask you for the parameter no of background process and no of parallel process.You can take a bigger value to reduce the downtime provided you have sufficient hardware.
Regards
Ashok Dalai
Edited by: Ashok Dalai on Aug 20, 2009 11:30 AM

Similar Messages

Downtime for upgrade from SP14 to SP23 - PI 7.0

Hello All,
What is the estimated downtime for upgrading PI7.0 from SP14 to SP23. We only have one application server in the environment and the decision to upgrade will happen based on the downtime information . Appreciate any response . Thanks Rahul.

Hi Rahul,
We have recently upgraded our PI 7.0 system from SP 21 to SP 21.
Basis team has requested for 19 hrs downtime. But the actual downtime that was required was less than 10 hours.
During upgrade, you have a downtime minimisation approach which would enable you to perform few actvities online without bringing down the system.
To follow this approach, Goto the transaction code "SAINT" --> Extras --> Settings --> Import Queue --> Import Mode.
There would be an option called "Downtime-minimized". Check that option so that you would be able to reduce the downtime during the upgrade.
Regards,
Subbu

Anybody know the estimate downtime for upgrade 10TB data 9i DB to 10gr2

Anybody know the estimate downtime for upgrade 10TB data 9i DB to 10gr2

Depend of the choosing method.
Depend if you move database, or if you stay on same server box.
Depend of processor you have.
In fact, the size of database is not directly implied during upgrade, that would be more regarding number of objects.
If I said you one hour, that won't be a big help. Manual upgrade may be very quick, but estimate time is not an easy task. Test on your test server and estimate for your production.
Nicolas.

Minimizing Downtime during Upgrade

Hi All,
We are in process of upgrade from R/3 4.7 EE 2.00 to ECC 6.0 SR3.
The details of legacy and new landscape is as follows :
Legacy Landscape
OS       Solaris 9
DB       Oracle 9.2.04
SAP     R/3 4.7 EE 2.00
New Landscape
OS       Solaris 10
DB       Oracle 10g
SAP     ECC 6.0 SR3
We have taken the offline backup of Live PRD and restored it on to Stand by server. We have also upgrade oracle 9i to 10g, which has taken around 20 hours.
My question is, we want to minimize the downtime by directly installing Oracle 10g with R/3 4.7 EE and the take the offline/online backup of live PRD system and restored back to oracle 10g enviroment. By doing this we can reduce the downtime by aprrox 15 hrs.
Is this scenario is possible ? Please give your valuable suggestion from your last experiences.
Thanks,
Kshitiz Goyal

> My question is, we want to minimize the downtime by directly installing Oracle 10g with R/3 4.7 EE and the take the offline/online backup of live PRD system and restored back to oracle 10g enviroment. By doing this we can reduce the downtime by aprrox 15 hrs.
Yes - this is possible.
I suggest you get the newest installation CD set for 4.7 which supports Oracle 10g (using sapinst, not R3SETUP):
See note "969519 - 6.20/6.40 Patch Collection Installation : Oracle/UNIX", Section 3:
3.) Retroactive Release of Oracle 10.2
Markus

Guidelines to reduce downtime during upgradation R/3 to ECC6

hi all........
Here we implemented SAP R/3 4.6 in the year 2005.
Now we are planning to upgrade our system to ECC6 unicode .
We are planning to upgrade our Production and Development system to SAP
ERP6 EHP4.As part of the upgradation; we had setup a test system with the
following details:
Sun Fire 480R (UltraSparc III + 1.05GHz x 4 processor)
Memory 16 GB and Storage : Sun CSM 200 SATA HDD
SAP R/3 4.71, single code pages 1100, Oracle 9.2.0.8.0, Solaris 9
Test system with 1.2TB data copied from Production System.
We have upgraded the test system using CU&UC method ( Upgrade Guide SAPERP6.0 EHP4 SR1 Abap ). It took 2 days downtime for full upgradation and 8 days for Unicode conversion.
Requirement :
To Upgrade the current systems without any additional hardware to SAP
ERP6 EHP4 Unicode.
As a part of the above, the cluster has to be upgraded to Sun cluster
3.2, and operating system to Solaris10 (5.10)
We are having the following queries:
1. With only 1.3 TB data, we feel, the down time of 10 days is not
realistic.Though we had not deviated from the above mentioned upgrade
guide, what could be the reasons for this down time of 10 days?what arethe affecting factors? Kindly suggest the ways by which we can get
reduced downtime . The referred Notes are (784118, 855772, 952514,
936441, 954268, 864861 ) still we are unable to pin point the reason. Abreak up of this down time is given below for reference.
2. Are there any alternate approved upgradation methods to reduce
downtime in our present set up? (details of present set up is given below)
3. How to calculate the down time with reference to(sapnote:857081) to in
our setup
Current Production System Details :
System : Sun Fire V890
Processor : 1.5GHz UltraSPARC IV+ processors -- 8no.s
Memory : 64 GB
Storage : Sun Storagetek 6180: HDD FCAL(16 no.s x 450 GB)
15,000-rpm 4 Gb/sec 4GB data cache (Storage connected to server using FC
cable)
SAP : R/3 4.71 single code pages 1100
Database : Oracle 9.2.0.8 data-size is around 1.3 TB
OS : Solaris 9 (5.9)
Cluster : Sun cluster 3.1
Network : 1GB ethernet (1000BASE-SX)
Architecture : Application and database server on Same system
SAP Development system specification same as the above with 187 GB data
size. PRD and DEV systems are on cluster; PRD failover to DEV system.
The time taken for test upgrade - brief details:
1. Kernel upgraded 6.20 to 6.40 (2hours)
2. Oracle Upgrade to 10.2.0.4.0 (3.30 hours)
3. SAP UPGRADE Preparation-Apply support packages (18 hours)
4. Downtime Phase and Pre-Processing and Finalization Phase (20 hours)
5. Unicode Conversion-Taking DB Export 109GB(Almost 10% of total DB
size)(98 hours)
6. Installation of unicode system using export (95 hours)
Looking forward to hear from you.
Best Regards,
Rajeesh K.P

Hi .......
i am very sorry for late reply...............................
The time taken for test upgrade - brief details:
1. Kernel upgraded 6.20 to 6.40 (2hours)
2. Oracle Upgrade to 10.2.0.4.0 (3.30 hours)
3. SAP UPGRADE Preparation-Apply support packages (18 hours)
4. Downtime Phase and Pre-Processing and Finalization Phase (20 hours)
5. Unicode Conversion-Taking DB Export 109GB(Almost 10% of total DB
size)(98 hours)
6. Installation of unicode system using export (95 hours)
2 days downtime means the sum of time used for above 4 activities ..........................
as you suggested we can do the same 4 different down times......................
Unicode Conversion-Taking DB Export 109GB(Almost 10% of total DB size) is taking a continuous down time
of 98 hours (4.5 days ) (Activity 5)+ installation of Unicode system using the Unicode export is taking 95 hours 4.5 days
(Activity 6)
i think the we have to do activity 5 & 6 in a single stretch with out users, so it will take a continuous down time of 9 Days
With this in mind I have a few questions for you to clear a little bit more all the problem.
Q:1 Did you use more parallel jobs during Downtime than default? and I mean real Downtime where the SAP system is taken down
No.we have used default number (3 ) of parallel jobs during downtime
Did the system allow you to use ICNV (incremental converssion) for some tables?
yes we may use ICNV
Can you separate the Unicode conversion to a different weekend? or is a must for some business reason?
Yes , we can separate the Unicode conversion to a different weekend , it will not affect our business
Did you save the post download Report so you can see what are the most time consuming phases?
i am not so clear about this question , we have made an activity chart with time duration as per the test upgrade. Or how we can save the post download report from the system
Looking forward to hear from you.
Best Regards,
Rajeesh K.P

Query to calculate downtime while upgrading from ECC to EHP4

Hi Folks,
I am having below doubts for calculating downtime phase for ehp4 downtime.
1.Do the end users will be able to work (In Production) in pre-processing phase in EHP4 upgrade u2026? (I think yes)
2.How we will count the downtime like from Preprocessing phase to until System is up ? or we will count from Downtime Phase. (I think from downtime phase)
Regards,
Sahil

Hi,
>
> 1.Do the end users will be able to work (In Production) in pre-processing phase in EHP4 upgrade u2026? (I think yes)
>
Yes. Users will be able to work till pre-processing phase.
> 2.How we will count the downtime like from Preprocessing phase to until System is up ? or we will count from Downtime Phase. (I think from downtime phase)
>
There is no formula to calculate downtime as it depends upon number of factors like system resources (RAM &CPU), no. of R3load processes, no. of background processes, Parameters tuning etc.
Do a test upgrade on your sandbox system (copy of production system) to get idea of downtime required.
Thanks
Sunny

Minimize downtime during UNICODE conversion

Hello forum !
I am looking at the UNICODE conversion of a large (?) SAP Oracle database for ECC. The Database it self is at about 10 TB. UNICODE converting this in one single run will take too long to fit inside the company defined tolerable downtime window.
When looking at the data I find that the largest 50 tables makes up about 75% of the total database size. Most of the 50 largest tables have data for several years back, and I am able to partition the tables with one partition pr year.
The good thing about this is that I am able to make the partitions with old data (more than one year old data) READ-ONLY.
My assumption is that I will be able to UNICODE convert 60-70% and create the indexes for these partitions without taking down the database to be converted.
Now,- doing the downtime-phase I will be able to exclude the old partitions of the largest tables in the export since I have already created a new UNICODE database with these objects and thereby drastically reducing the required downtime.
Is there anyone who has any experience with an approach like the one I have schetched out here ?
Kjell Erik Furnes

Can you please be a bit more specific on your installation? How long is your possible downtime (export time should be about 2/3 of that)? How long is your actual export estimation? Do you have suitable hardware (CPU/disk)?
What you absolutely need to have:
[1043380 - Efficient Table Splitting for Oracle Databases|https://service.sap.com/sap/support/notes/1043380] -> export tables with ROWID splitting
[855772 - Distribution Monitor|https://service.sap.com/sap/support/notes/855772] -> enables distributed and parallel export/import
So on the hardware side you will need, a storage subsystem as fast as possible with two copies of the disks (one for exporting and one for importing). A bunch of application servers with fast CPUs helps a lot, everything connected with at least gigabit ethernet.
If you knew all this already, sorry for the spam. But i achived throughputs at about 400gb/hour on a medium sized hardware, i think throughputs of 1tb/hour should be possible (not talking about cluster tables
Regards, Michael

I need Patchset to upgrade from 11.1.0.6 to 11.2.0

I need patch set to upgrade 11.1.0.6 and which patch set is available to upgrade from 11.1.0.6 to 11.2.0.1 or 11.2.0.2
Please suggest .
Thanks
Edited by: 845470 on Jul 23, 2012 4:00 AM

As John noted, this is not a patch, but a complete upgrade. At a high level, you will need to
1. Install 11gR2 into a new ORACLE_HOME
2. Upgrade from 11.1.0.6 to 11gR2 using the Upgrade Guide - http://docs.oracle.com/cd/E11882_01/server.112/e23633/toc.htm
Pl also see these MOS Docs
Oracle 11gR2 Upgrade Companion [ID 785351.1]
Complete Checklist to Upgrade the Database to 11gR2 using DBUA [ID 870814.1]
Best Practices to Minimize Downtime During Upgrade [ID 455744.1]
Best approach for Oracle database patching sequence to latest/required patchset along with CPU/PSU/any-other-one-off patch [ID 865255.1]
HTH
Srini

Upgrade Oracle 10gR2 RAC to 11gR2 RAC

Hi Gurus,
I got a requirement to upgrade my existing environment from Oracle 10gR2 RAC to 11gR2 RAC. My environment details are as follows
Operating system RHEL 5.5
Cluster version 10.2.0.4
ASM version 10.2.0.4
Database version 10.2.0.4
Storage HP EVA (Multipathing)
Could any one please specify the links or documents to complete this task!
Thanks & Regards,
Venkat

HI!
In my practise we have hardware to move 10g -> 11g.
We upgrade our DB's -> install Grid 11g on new server, move DB 10g, Upgrade 10g -> 11g.
You should work on this topic's:
Oracle® Database Upgrade Guide 11g Release 2 (11.2)
NEW FEATURES 11gr2
Complete Checklist for Manual Upgrades to 11gR2
Oracle Recommended Patches
Oracle Clusterware - ASM - Database Version Compatibility
How to Download and Run Oracle's Database Pre-Upgrade Utility
Best Practices to Minimize Downtime During Upgrade
Things to Consider Before Upgrading to 11.2.0.2 Grid Infrastructure
Different Upgrade Methods For Upgrading Your Database
All in you hands!!!

Solution Reqd for having less downtime

Hi All
we are migrating the oracle db ver9i to 11g. we have huge data say 40 million. when we check with our dba, they have estimated the downtime to be for 4-5 days. for upgrade and do cathup to a new host with r12. we have many important subscribers for our service, for which they do not give that much time. we have explored many solutions like golden gate and all couldnt find anything usful, but finally decided to collect all dml sqls in an order.
What i need is can we have a schema lelvel trigger to capture all dmls during 4days downtime. if not pls suggest
for any other alternative ways.
Thanks
Surendra

Pl post details of exact versions of OS and database for source and target.
The size of the database or the number of records do not have anything to do with how long the upgrade will take. The 11g software install can be performed in advance and should not take more than an hour. The actual upgrade itself should take no more than 8 to 12 hours, assuming you are upgrading "in-place" (i.e. on the same server). If not, you will need to add time needed to copy the database to the new server, which will take time depending on how big your database is.
An in-place upgrade can be achieved well within 24 hours. Also see these MOS Docs
455744.1 - Best Practices to Minimize Downtime During Upgrade
739485.1 - How to estimate the time required to upgrade a database ?
HTH
Srini

Data Guard or Golden Gate

Hello Fellows
I want to migrate an oracle 9i to 11g and I am not sure which is the best way to migrate my database.
Data Guard or Golden Gate
Thanks in advance
Panos
Edited by: user9141133 on 19 Σεπ 2011 2:50 πμ

Although it is true that Golden Gate & Data Guard have a different main purpose, they can very well be used during an upgrade rsp. a migration to minimize the associated downtime.
See for example how Data Guard can be used to minimize downtime for upgrade here:
http://uhesse.wordpress.com/2011/08/10/rolling-upgrade-with-transient-logical-standby/
Kind regards
Uwe Hesse
http://uhesse.wordpress.com

Recommended upgrade method from ECC5 to ECC6 for lowest production downtime

Hello everybody,
I've been looking through multiple documents concerning a system upgrade and I am still unable to figure out the recommended method for upgrading a system with minimum downtime.
My scenario requires that tests as rigid as possible will be performed and that development will be halted for the shortest time possible , therefore development must be continued after the initial upgrade.
We are currently debating the required way to do this - what should be done with the change requests that currently reside in the DEV system, in which steps the incomptabilities are fixed and so on.
I've decided that I'll share my thoughts with you and maybe you guros will be able to point out mistakes in the methodology.
1. ECC 5 Production System is copied aside, lets call this system EPC
2. Change requests from DEV ECC5 are copied to this EPC System.
3. EPC system is upgraded to ECC6.
4. Bugs and incomptabilities such as unicode incomptabilities are fixed and merged in a change request
This ends the preperation step and in my opinion is sort of a preperation step.
During the whole preparation step, which to my estimate could take at least one month, development in the original system must be continued, so this is my main trouble.
What is the recommended procedure from here?
I assume that another production must be done on the day of the actual upgrade start, then the fixes from the previous preperation system are copied to this actual ECC6 Production, but I am rather lost as far as it goes to having an ECC6 Dev with most current change requests.
I would appreciate any hints and help,
thanks in advance,
Eli.

Ok, your idea of having a production copy for development and tests is a good upgrade strategy, we have done this twice due high quantity of developments and configuragion changes but I don´t see why you wrote " copy change requests from DEV to EPC " your whole configuration, programs, etc, are already in EPC once you copy the system.
In this scenario every change made in DEV ECC 5.0 must be also replicated and tested in EPC 6.0 because you cannot use the change requests from 5.0 in 6.0 once in productive upgrade, let me list the global steps:
1.- Homogeneous system copy from PRD to EPC, you will get a working test platform
2.- Upgrade EPC to 6.0
3.- Developers and functionals will do all respective changes and generate chage requests.
Once EPC is ready
4.- Upgrade DEV system to 6.0 transport change requests created in EPC to upgraded DEV, from this point you should only do emergency changes using Q&A system.
5.- Upgrade Q&A system, transport change requests from DEV, no changes are permited from now until PRD is upgraded.
6.- Do all tests very carefully
7.- Upgrade PRD transport change requests
Then you are ready. the downtime can be tune trough EPC, DEV and Q&A systems so you can determine what you shoud do to assure the shortest method.
I recomend you to use the downtime minimized upgrade method and from every upgrade take a deep look at the upgrade report generated after the whole process is completed.

Want to upgrade 9i to 10g without downtime

Hi Experts
I have a 9i database which is running our ecommerce database it is a database which is running smoothly now , however i need to update it to 10g database as all our other databases are in 10g , is there a way without downtime i can achieve this .
Ii do not have an option to shutdown the database , i have allowed at the most few seconds to achieve this . Can anyone suggest me some workable steps by way of which i can achieve this.
Probably something like a replication technique ?
Thanks Experts.

My "environment" uses both TNS and Java, and it takes about 5 to 30 minutes to update all database references, plus the time needed to stop all of the components, which can be anything between 5 minutes and X hours.
When reading the Oracle whitepaper called "Zero Downtime Database Upgrade Using Oracle GoldenGate", it clearly says : no downtime for the database. That part is correct. But then it says, "..very minimal time required for application switchover, typically less than one minute and in most cases, only seconds."
That's way understated, but I understand that it must fit into the "Zero Downtime" idea.
For my application, it's about between 10 minutes and X hours. It's typical for database procedures to underestimate the impact of the application. How else can one make such general statements, knowing there are hundreds and thousand sorts of applications (all Oracle), then stating - without actually knowing how they work - one can switch in 1 second. Even when dreaming, that's a bit optimistic.
But the question may to the thread opener : no database downtime, or no application downtime ?
Know that if the application has downtime, the fact that the database goes down or not (for a shorter time than the application downtime) is actually of no importance. Because end-users cannot connect anyway.

Cisco ASA non zero downtime upgrade

Hello,
with a NON zero downtime procedure upgrade all connections are lost, even nat and arp table ? here, http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/configuration/guide/asa_84_cli_config/ha_overview.html#wp1078922, on Table 61-2 State Information I think it is only for plain failover but not for upgrade with a non zero downtime upgrade procedure.

Assuming you have a working HA pair with stateful failover, the Cisco supported answer is that you cannot skip minor releases (i.e. going from 9.1 directly to 9.3).
You CAN upgrade directly from 9.1(2) to 9.1(5) as that third ordinal (the number in parentheses) is known as the maintenance release level.
See table 1-6 in the Release notes for confirmation, excerpted here:
"You can upgrade from any maintenance release to any other maintenance release within a minor release.
For example, you can upgrade from 8.4(1) to 8.4(6) without first installing the maintenance releases in between."
Note that 9.1(3) or later have some restrictions that are unique to those more recent code levels as some file system changes were put in place that requires certain prerequisites for a successful upgrade. Given that you are on 9.1(2) already that doesn't affect you in this case but it may be a consideration for other readers. Those requirements are noted just above Table 1-6 in those release notes.

XPRAS_UPG error in DOWNTIME phase in EHP4

Hi,
I am getting the below error in XPRAS_UPG in DOWNTIME phase of EHP4 installation in ERP 6.0 on HP-UNIX and Oracle.
XPRA ERRORS and RETURN CODE in SAPRW70104.HD1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1AETR012XProgram terminated (job: "RDDEXECL", no.: "10302400")
Long text:
    Cause
      Program "&V#&", which was started in the background, was terminated
      abnormally.
    System Response
      The system created a job log for the terminated program.
    What to do
      Proceed as follows:
      Log onto the system in which the program was executed. The system is
      specified at the beginning of the transport log.
      Then call transaction SM37 to display the job log.
      Enter "&V#&" as job name and "DDIC" as user name.
      Restrict the starting date to the starting date specified in the
      transport log.
      For the other selection criteria, select only jobs with the status
      "cancelled". Then press <LS>Execute</>.
      A list of the jobs satisfying the selection criteria is displayed.
      You can display the log by pressing <LS>Job log</>.
      If the list contains several jobs, you can select the job with the ID "
      &V#&" with <LS>Display</> -> <LS>Job details</> or define further
      details for the selection criteria in the initial screen of transaction
      SM37.
      If the ABAP processor reports cancellation, double-clicking on the
      corresponding message in the job log branches to the display of the
      corresponding short dump.
1AEPU320 See job log"RDDEXECL""10302400""HD1"
1 ETP111 exit code           : "12"
>>> PLEASE READ THE REPORT DOCUMENTATION OF THE REPORTS MENTIONED ABOVE <<<
XPRAs are application reports that run at the end of an upgrade.
Most XPRA reports have a report documentation that explains what
the report does and how errors can be corrected.
Call transaction se38 in the SAP system, enter the report name,
select 'Documentation' and click the 'Display' button.
>>> The problematic XPRAs are mentioned in messages of type PU132 above <<<
I was successfully able to umlock the system and in SM37 I could see the job log pointing to ST22. In ST22 we have many dumps related to error PXA_NO_FREE_SPACE. I found many notes in marketplace but all are referring the parameter abap/buffersize which needs to increased. I am a bit apprehensive about the fact that since we are in DOWNTIME phase and in the middle of XPRA execution phase should we increase the parameter and restart the system and then continue with the upgrade???
I have also tried to run the phase many times but the same error persists.
Please can anyone help me to come out of this problem.....
Thanks & regards,
Rozal

Hello Rozal,
You are correct XPRAS is a downtime 2 phase, but actually your system is up and running. It was started way back in phase "STARTSAP_NBAS" its just that you cannot use your system productively. XPRAS executes the XPRAS methods in the running system.
Its absolutely safe, you can change the parameter take a restart and continue further.
- Niraj

XPRA to minimize downtime durina upgrade

Similar Messages

Maybe you are looking for