Best Practice for upgrading to 11.1.1.3

Hi,
Can anyone tell me what is the best practice to upgrade FMW to 11.1.1.3...
I followed the following steps to set up FMW 11.1.1.3.
1. Oracle Enterprise edition Database 10.2.0.1 and applied 10.2.0.4 patch
2. Installed RCU 11.1.1.3
3. Installed Weblogic server 10.3.3 (11gR1)
4. Installed Soa Suite 11.1.1.2 and applied patch for 11.1.1.3
Is this the right way of installation or do i have to install 11.1.1.2 first f and then install 11.1.1.3..
Regards,
Sundar

Yes, that seems to be fine.
regards

Similar Messages

Best practice for upgrading task definition without deleting task instances

best practice for upgrading task definition in production system without deleting or terminating task instances
If I try and update a task definition with task instances running I get the following error:
Task definition 'My Task - Add User' may not be modified while there are active task instances
Is there a best practice to handle this. I tried to force an update through the console but that didn't work. I tried editing the task from the debug page and got the same error.

1) Rename the original task definition.
2) Upload the new task definition with the original name.
3) Later, after all the running tasks have timed out, delete the old definition.
E.g., if your task definition is "myWorkflow":
1) Rename "myWorkflow" to "myWorkflow-old-2009-07-28"
2) Upload the new task definition as "myWorkflow".
Existing tasks will stay linked to the original (renamed) workflow definition.
New tasks will use the new definition.
As the previous poster notes, depending on the changes you are making, letting the old task definitions stay active could have bad side-effects and might be better avoided.

Best practice for upgrading task definition in production system

If I try and update a task definition with task instances running I get the following error:
Task definition 'My Task - Add User' may not be modified while there are active task instances
Is there a best practice to handle this. I tried to force an update through the console but that didn't work. I tried editing the task from the debug page and got the same error.

The best way for upgrade purposes is to use the rename function of the TaskDefinition from the lh command line utility.
Basically renames all current task instances with the TaskDefinition name. You can then alter the existing TaskDefinition and upload into identity manager.

Best practice for upgrading from ADS 9.1 to ADS 11

So we will need start upgrading installs from Advantage Database Server (ADS) version 9 to ADS version 11. Is there a set of best practices? Certain procedures? How do we gracefully fall back if it doesn't work? Does anyone have experience with the dual install setup of ADS 9 and ADS 11? Did anyone else run into any issues with this upgrade path?
Thanks in advance!
Rodney

Rodney,
My first recommendation is to read the "Effects of Upgrading" section of the help file. I put the links below.
Effects of Upgrading to Version 10
Effects of Upgrading to Version 11
Effects of Upgrading to Version 11.1
The server will always work with an older client so I would recommend upgrading the server and testing it with your current application. The next step would be to upgrade the client and re-compile your application. I wouldn't anticipate any issues other than those outlined in the effects of upgrading.
You can install multiple instances of Advantage, beginning with version 10, on the same machine. Keep in mind that only one instance, the first one installed, will be discoverable. To connect to other instances you will need to use <IP Address>:<Port> in the connection string. Details on installing additional instances of Advantage are here
Chris

Best practice for upgrading an old system?

My Archlinux installation seems to have been upgraded over three years ago for the last time. Today, a naive pacman -Syu resulted in a number of file conflict errors and wasn't carried out.
I then checked the list of announcements since 2011 and identified a few that included the string "manual intervention required". I believe that it was the update of the "filesystems" package that didn't work, again due to conflicts, probably related to the move from /lib to /usr/lib around that time.
My attempt to update glibc resulted in misconfigured libraries, which took a while to sort out. While I can run commands again, I doubt that my system is in a very healthy state now.
What should I do, what should I have done to update my Archlinux installation, untouched for 3.5 years?
Last edited by berndbausch (2014-08-31 04:14:50)

SoleSoul wrote:If 'pacman -Syu' works now, what makes you ask this question? Is anything still broken?
Well, I asked the question because nothing worked after following a few of those "manual intervention required" notes. More precisely, the result of the last pacman was that literally no command worked. It turned out that the system didn't find libraries anymore, in particular the loader ld-linux.so. It took me a while to figure this out and to patch the system up enough to have it limp along. Good learning, by the way.
After that and the suggestion in this forum that a reinstall was the best solution anyway I did just that. Since my only applications were Samba and the acpi daemon, that was not too bad. Unfortunately it's not Archlinux anymore, but Centos, which I am simply more familiar with.

Best Practice for Upgrade in FPN-Landscape

Hi there,
we have already implemented a consumerportal with two producerportals.
Now we want to upgrade our consumerportal from SPS12 to SPS15.
It´s better to disconnect the producer and reconnect these portal after upgrading again?
Or it´s not a problem to upgrade a consumerportal while producer are connected?
Same question in other way. If we upgrade a producersystem. May we disconnect these portals until the upgrade on producersystem is done and connect again?
Wait for your helpful experience :o)
Best regards
Christian

It´s better to disconnect the consumersystem from producer.
After Upgrad all is fine.

Best Practices for Upgrade UCS firmware from 2.0 to 2.2?

Hi
I have Cisco UCS system ( 2 FI, 4 Chassis with 32 Server ) running 2.0 firmware. Now I want upgrade to 2.2. When I check document "Upgrading Cisco UCS from Release 2.0 to Release 2.2", I see have 2 solution:
- 1. Upgrading from Release 2.0 with Auto Install -> Step simple but all server reboot at same time.
- 2. Manually Upgrading from Release 2.0. -> Step more complex but can upgrade server one by one.
My question:
- Can I "Upgrade the infrastructure firmware with Auto Intall but upgrade Server with Manual"?
- What is best for my case?
Thanks

Hi Phamcongtuan,
In UCS you can create host firmware policy that can be used to upgrade the firmware of your blades. Once you upgrade the infrastructure firmware, you can apply the host firmware policy to the service profiles of your blades. If you are using service profiles templates you will need to unbind the service profiles and apply the policy to the individual servers.
Host Firmware Package
http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/sw/firmware-mgmt/cli/2-2/b_CLI_Firmware_Management_22/b_CLI_Firmware_Management_22_chapter_01000.html#concept_6982A188474A452CBFDBBDD7DD4921F3

Best practices for upgrading Windows Server Essentials 2012 to R2?

Hi,
I need to upgrade my Windows Server Essentials 2012 on an HP microserver to Essentials R2 (specifically the R2 role on Standard rather than as a VM). After a reasonable amount of searching, I haven't found anything online that specifically addresses this in-place
upgrade scenario. Since this is already an Essentials server, it's the PDC in its own domain, etc. Has anyone that's done this upgrade have any experiences or warnings to share?
Thanks,
Sean

Hello there,
There is no upgrade path from Server 2012 Essentials to R2. R2 is not an upgrade, it is a new build. Essentials does not upgrade easily, you will want to perform a migration of the server. This will require additional hardware. You
can possibly backup the 2012 Essentials, build a temp server on workstation hardware just to do the migration from, restore the backup to the new server and then perform the migration to R2.

SAP Best Practice For Unicode Upgrades - NetWeaver 2004s

Team SAP,
I have a customer that is starting to plan for a Unicode upgrade. The question from the customer is as follows:
What is the SAP Best Practice for Unicode Upgrades? They will be upgrading from a BW 3.5 System to NetWeaver 2004s, and their question is ... should they:
a) Perform the Unicode Upgrade At The Same Time As Their BW 3.5 > NetWeaver 2004s Upgrade, or
b) Perform NetWeaver 2004s Upgrade first, and then at a later date, perform the Unicode Upgrade?
Thank you in advance for any guidance or counsel you may be able to offer.
-M

Hi Michael,
Check these links:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ee7407a0-0501-0010-81ae-e329029b1074
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/7e259990-0201-0010-6085-e7c5aec5af1d
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/5411d290-0201-0010-b49b-a6145fb16d15
Bye
Dinesh

Best practices for setting up users on a small office network?

Hello,
I am setting up a small office and am wondering what the best practices/steps are to setup/manage the admin, user logins and sharing privileges for the below setup:
Users: 5 users on new iMacs (x3) and upgraded G4s (x2)
Video Editing Suite: Want to connect a new iMac and a Mac Pro, on an open login (multiple users)
All machines are to be able to connect to the network, peripherals and external hard drive. Also, I would like to setup drop boxes as well to easily share files between the computers (I was thinking of using the external harddrive for this).
Thank you,

Hi,
Thanks for your posting.
When you install AD DS in the hub or staging site, disconnect the installed domain controller, and then ship the computer to the remote site, you are disconnecting a viable domain controller from the replication topology.
For more and detail information, please refer to:
Best Practices for Adding Domain Controllers in Remote Sites
http://technet.microsoft.com/en-us/library/cc794962(v=ws.10).aspx
Regards.
Vivian Wang

What are the best practices for using the enhancement framework?

Hello enhancement framework experts,
Recently, my company upgraded to SAP NW 7.1 EhP6. This presents us with the capability to use the enhancement framework.
A couple of senior programmers were asked to deliver a guideline for use of the framework. They published the following statement:
"SAP does not guarantee the validity of the enhancement points in future releases/versions. As a result, any implemented enhancement points may require significant work during upgrades. So, enhancement points should essentially be used as an alternative to core modifications, which is a rare scenario.".
I am looking for confirmation or contradiction to the statement "SAP does not guarantee the validity of enhancement points in future releases/versions..." . Is this a true statement for both implicit and explicit enhancement points?
Is the impact of activated explicit and implicit enhancements much greater to an SAP upgrade than BAdi's and user exits?
Is there any SAP published guidelines/best practices for use of the enhancement framework?
Thank you,
Kimberly
Edited by: Kimberly Carmack on Aug 11, 2011 5:31 PM

Found an article that answers this question quite well:
[How to Get the Most From the Enhancement and Switch Framework as a Customer or Partner - Tips from the Experts|http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/c0f0373e-a915-2e10-6e88-d4de0c725ab3]
Thank you Thomas Weiss!

Best practice for migrating IDOCs?

Subject: Best practice for migrating IDOC's?
Hi,
I need to migrate some IDOC's to another system for 'historical reference'.
However, I don't want to move them using the regular setup as I don't want the inbound processing to be triggered.
The data that was created in the original system by the processed IDOC's will be migrated to the new system using migration workbench. I only need to migrate the IDOC's as-is due to legal requirements.
What is the best way to do this? I can see three solutions:
A) Download IDOC table contents to a local file and upload them in the new system. Quick and dirty approach, but it might also be a bit risky.
B) Use LSMW. However, I'm not sure whether this is feasible for IDOC's.
C) Using ALE and setting up a custom partner profile where inbound processing only writes the IDOC's to the database. Send the IDOC's from legacy to the new system. Using standard functionality in this way seems to me to be the best solution, but I need to make sure that the IDOC's once migration will get the same status as they had in the old system.
Any help/input will be appreciated
Regards
Karl Johan
PS. For anyone interested in the business case: Within EU the utility market was deregulated a few years ago, so that any customer can buy electricity from any supplier. When a customer switches supplier this is handled via EDI, in SAP using ALE and IDOC's. I'm working on a merger between two utility companies and for legal reasons we need to move the IDOC's. Any other data is migrated using migration workbench for IS-U.

Hi Daniele
I am not entirely sure, what you are asking, Please could you provide additional information.
Are you looking for best practice recommendations for Governance, for example: Change transports between DEV, QA and PRD in BPC 7.0?
What is the best method? Server Manager backup and restore, etc ?
And
Best Practice recommendations on how to upgrade to a different version of BPC, for example: Upgrading from BPC 7.0 to 7.5 or 10.0 ?
Kind Regards
Daniel

Best practice for distributing/releasing J2EE applications.

Hi All,
We are developing a J2EE application and would like some information on the best
practices to be followed for distributing/releasing J2EE applications, in general.
In particular, the dilemma we have is centered around the generation of stub, skeleton
and additional classes for the application.
Most App. Servers can generate the required classes while deploying the EJBs in the
application i.e. at install time. While some ( BEA Weblogic and IBM Websphere are
two that we are aware of ) allow these classes to be generated before the installation
time and the .ear file containing the additional classes is the one that is uploaded.
For instance, say we have assembled the application "myapp.ear" . There are two ways
in which the classes can be generated. The first is using 'ejbc' ( assume we are
using BEA Weblogic ), which generates the stub, skeleton and additional classes for
the application and returns the file, say, "Deployable_myapp.ear" containing all
the necessary classes and files. This file is the one that is then installed. The
other option is to install the file "myapp.ear" and let the Weblogic App. server
itself, generate the required classes at the installation time.
If the first way, of 'pre-generating' the stubs is followed, does it require us to
separately generate the stubs for each versions of the App. Server that we support
? i.e. if we generate a deployable file having the required classes using the 'ejbc'
of Weblogic Ver5.1, can the same file be installed on Weblogic Ver6.1 or do we
have to generate a separate file?
If the second method, of 'install-time-generation' of stubs is used, what is the
nature/magnitude of the risk that we are taking in terms of the failure of the installation
Any links to useful resources as well as comments/suggestions will be appreciated.
TIA
Regards,
Aasif

Its much easier to distribute schema/data from an older version to a newer one than the other way around. Nearly all SQL Server deployment features supports database version upgrade, and these include the "Copy Database" wizard, BACKUP/RESTORE,
detach/attach, script generation, Microsoft Sync framework, and a few others.
EVEN if you just want to distribute schemas, you may want to distribute the entire database, and then truncate the tables to purge data.
Backing up and restoring your database is by far the most RELIABLE method of distributing it, but it may not be pratical in some cases because you'll need to generate a new backup every time a schema change occurs, but not if you already have an automated
backup/maintenance routine in your environment.
As an alternative, you can Copy Database functionality in SSMS, although it may present itself unstable in some situations, specially if you are distributing across multiple subnets and/or domains. It will also require you to purge data if/when applicable.
Another option is to detach your database, copy its files, and then attach them in both the source and destination instances. It will generate downtime for your detached databases, so there are better methods for distribution available.
And then there is the previously mentioned method of generating scripts for schema, and then using an INSERT statement or the import data wizard available in SSMS (which is very practical and implements a SSIS package internally that can be saved for repeated
executions). Works fine, not as practical as the other options, but is the best way for distributing databases when their version is being downgraded.
With all this said, there is no "best practice" for this. There are multiple features, each offering their own advantages and downfalls which allow them to align to different business requirements.

What are best practice for packaging and deploying j2EE apps to iAS?

We've been running a set of J2EE applications on a pair of iAS SP1b for about a year and it has been quite stable.
Recently however we have had a number of LDAP issues, particularly when registering and unregistering applications (registering ear files sometimes fails 1st time but may work 2nd time). Also We've noticed very occasionally that old versions of classes sometimes find their way onto our machines.
What is considered to be best practice in terms of packaging and deployment, specifically:
1) Packaging - using the deployTool that comes with iAS6 SP1b to package is a big manual task, especially when you have 200+ jsp files. Are people out there using this or are they scripting it with a build tool such as Ant?
2) Deploying an existing application to multiple iAS's. Are you guys unregistering old application then reregistering new application? Are you shutting down iAS whilst doing the deployment?
3) Deploying ear files can take 5 to 10 mins, is this normal?
4) In a clustered scenario where HTTPSession is shared what are the consequences of doing deployments to data stored in session?
thanks in asvance for your replies
Owen

You may want to consider upgrading your application server environment to a newer service pack. There are numerous enhancements involving the deployment tool and run time layout of your application that make clear where you're application is loading its files from.
If you've at a long running application server environment, with lots of deployments under your belt, you might start to notice slow downs in deployment and kjs start time. Generally this is due to garbage collecting in your iAS registry.
You can do several things to resolve this. The most complete solution is to reinstall the application server. This will guarantee a clean ldap registry. Of course you've got to restablish your configurations and redeploy your applications. When done, backup your application server install space with the application server and directory server off. You can use this backup to return to a known configuation at some future time.
For the second method: <B>BE CAREFUL - BACKUP FIRST</B>
There is a more exhaustive solution that involves examining your deployed components to determine the active GUIDS. You then search the NameTrans section of the registry searching for Applogic Servlet *, and Bean * entries that represent your previously deployed components but are represented in the set of deployed GUIDs. Record these older GUIDs, remove them from ClassImp and ClassDef. Finally remove the older entries from NameTrans.
Best practices for deployment depend on your particular environmental needs. Many people utilize ANT as a build tool. In later versions of the application server, complete ANT scripts are included that address compiling, assembly and deployment. Ant 1.4 includes iAS specific targets and general J2EE targets. There are iAS specific targets that can be utilized with the 1.3 version. Specialized build targets are not required however to deploy to iAS.
Newer versions of the deployment tool allow you to specify that JSPs are not to be registered automatically. This can be significant if deployment times lag. Registered JSP's however benefit more fully from the services that iAS offers.
2) In general it is better to undeploy then redeploy. However, if you know that you're not changing GUIDs, recreating an existing application with new GUIDs, or removing registered components, you may avoid the undeploy phase.
If you shut down the KJS processes during deployment you can eliminate some addition workload on the LDAP server which really gets pounded during deployment. This is because the KJS processes detect changes and do registry loads to repopulate their caches. This can happen many times during a deployment and does not provide any benefit.
3) Deploying can be a lengthy process. There have been improvements in that performance from service pack to service pack but unfortunately you wont see dramatic drops in deployment times.
One thing you can do to reduce deployment times is to understand the type of deployment. If you have not manipulated your deployment descriptors in any way, then there is no need to deploy. Simply drop your newer bits in to the run time space of the application server. In later service packs this means exploding the package (ear,war, or jar) in to the appropriate subdirectory of the APPS directory.
4) If you've changed the classes of objects that have been placed in HTTPSession, you may find that you can no longer utilize those objects. For that reason, it is suggested that objects placed in session be kept as simple as possible in order to minimize this effect. In general however, is not a good idea to change a web application during the life span of a session.

Best Practice for Distributing Databases to Customers

I did a little searching and was surprised to not find a best practice document for how to distribute Microsoft SQL Databases. With other database formats, it's common to distribute them as scripts. It seems that feature is rather limited with the built-in
tools Microsoft provides. There appear to be limits to the length of the script. We're looking to distribute a database several GBs in size. We could detach the database or provide a backup, but that has its own disadvantages by limiting what versions
of the SQL Server will accept the database.
What do you recommend and can you point me to some documentation that handles this practice?
Thank you.

Its much easier to distribute schema/data from an older version to a newer one than the other way around. Nearly all SQL Server deployment features supports database version upgrade, and these include the "Copy Database" wizard, BACKUP/RESTORE,
detach/attach, script generation, Microsoft Sync framework, and a few others.
EVEN if you just want to distribute schemas, you may want to distribute the entire database, and then truncate the tables to purge data.
Backing up and restoring your database is by far the most RELIABLE method of distributing it, but it may not be pratical in some cases because you'll need to generate a new backup every time a schema change occurs, but not if you already have an automated
backup/maintenance routine in your environment.
As an alternative, you can Copy Database functionality in SSMS, although it may present itself unstable in some situations, specially if you are distributing across multiple subnets and/or domains. It will also require you to purge data if/when applicable.
Another option is to detach your database, copy its files, and then attach them in both the source and destination instances. It will generate downtime for your detached databases, so there are better methods for distribution available.
And then there is the previously mentioned method of generating scripts for schema, and then using an INSERT statement or the import data wizard available in SSMS (which is very practical and implements a SSIS package internally that can be saved for repeated
executions). Works fine, not as practical as the other options, but is the best way for distributing databases when their version is being downgraded.
With all this said, there is no "best practice" for this. There are multiple features, each offering their own advantages and downfalls which allow them to align to different business requirements.

Best Practice for upgrading to 11.1.1.3

Similar Messages

Maybe you are looking for