Return-Path: X-Original-To: oracle-l@orafaq.com Delivered-To: oracle-l@orafaq.com Received: from puck1183.startdedicated.com (localhost [127.0.0.1]) by puck1183.startdedicated.com (Postfix) with ESMTP id B239F19602A0 for ; Fri, 6 Jun 2014 20:46:38 +0200 (CEST) Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by puck1183.startdedicated.com (Postfix) with ESMTP for ; Fri, 6 Jun 2014 20:46:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 220E12A163; Fri, 6 Jun 2014 14:46:14 -0400 (EDT) Authentication-Results: turing.freelists.org; dkim=fail (verification failed; insecure key) header.i=@gmail.com; dkim-adsp=none (insecure policy) X-Virus-Scanned: Debian amavisd-new at turing.freelists.org Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz2KVJKHiuWL; Fri, 6 Jun 2014 14:46:14 -0400 (EDT) Received: from turing.freelists.org (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id BF84420A37; Fri, 6 Jun 2014 14:45:32 -0400 (EDT) Received: with ECARTIS (v1.0.0; list oracle-l); Fri, 06 Jun 2014 14:44:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 856C52C5B2 for ; Fri, 6 Jun 2014 14:44:51 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS6ZPXXAY4aP for ; Fri, 6 Jun 2014 14:44:51 -0400 (EDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 45BBE2C5AF for ; Fri, 6 Jun 2014 14:44:27 -0400 (EDT) Received: by mail-qg0-f44.google.com with SMTP id i50so5304514qgf.3 for ; Fri, 06 Jun 2014 11:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=leEX17uGqIEXaIw+o8gKO7cfZlV9MVk4TxLx+Qhky7c=; b=AEHZNRitvPUN3GFPjzbT2G2iClLRSxxrfthmNI66A3ay5QLc4MBiC7G6A9iRIlQFZk 1ebfxyOqtLEN5v9cSkua7Zkf8NAb/grRmX8t0b+PD9ykdjaikzQvkX1NmiLgrOvPxrVd joz9dtBeM7B7ES8xyL8D6c/GNokeEuOi8xDOAJrO52aEE6FH3SrZSmK5Qsp1OV0rMSaG e5u6SVl4G4Fi1asejpe2eIQM6FJyD+6NjZXfHWEtQYrCKzwU6oC1aNwZvMYK8qyA8dNL Ru9uWHp3jlNXRiDHGsX8ZXpKjYONtoDbTjKeUU5YLnl6mXlq4uGeqg9GcOYqaiIz8Xes pEnQ== MIME-Version: 1.0 X-Received: by 10.224.161.138 with SMTP id r10mr12292924qax.2.1402080267123; Fri, 06 Jun 2014 11:44:27 -0700 (PDT) Received: by 10.170.167.198 with HTTP; Fri, 6 Jun 2014 11:44:27 -0700 (PDT) Received: by 10.170.167.198 with HTTP; Fri, 6 Jun 2014 11:44:27 -0700 (PDT) In-Reply-To: <3653B77DCF6DDA4ABAD1E9416F1876D73FEDE52C@ex03mail01.ad.rit.edu> References: <3653B77DCF6DDA4ABAD1E9416F1876D73FEDE52C@ex03mail01.ad.rit.edu> Date: Fri, 6 Jun 2014 19:44:27 +0100 Message-ID: Subject: RE: Move to new hardware and upgrade o/s From: Ronan Merrick To: srcdco@rit.edu Cc: "mcunningham@thedoctors.com" , oracle-l , "ksmadduri@gmail.com" Content-Type: multipart/alternative; boundary=089e014953ec44dd3e04fb2f4014 X-archive-position: 54888 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-to: oracle-l-bounce@freelists.org X-original-sender: merrickronan1@gmail.com Precedence: normal Reply-To: merrickronan1@gmail.com List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: oracle-l X-List-ID: oracle-l List-subscribe: List-owner: List-post: List-archive: X-list: oracle-l --089e014953ec44dd3e04fb2f4014 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, When I did this the sysadmin installed the new server and called it oracle01a. We had all the database files on LUNs. We swapped the LUNS over to the new server and then renamed the old server to Oracle01b and the new one to Oracle01. We had to wait a little while for the changes to synchronise across the whole network, but we didn't have to change any tnsnames. On 6 Jun 2014 18:59, "Scott Canaan" wrote: > If all you are concerned about is pointing to the new server, then use > DNS and make the change there. That way the users won=E2=80=99t even kno= w the > server changed IPs and the DNS alias would handle that. That=E2=80=99s t= he way we > handle moves from one server to another. > > We use impdp over the network to move the data over. > > > > Scott Canaan =E2=80=9988 (srcdco@rit.edu) > > (585) 475-7886 =E2=80=93 work (585) 339-8659 =E2=80=93 cel= l > > =E2=80=9CLife is like a sewer, what you get out of it depends on what you= put into > it.=E2=80=9D =E2=80=93 Tom Lehrer > > > > *From:* oracle-l-bounce@freelists.org [mailto: > oracle-l-bounce@freelists.org] *On Behalf Of *Cunningham, Mike > *Sent:* Friday, June 06, 2014 1:41 PM > *To:* ksmadduri@gmail.com; oracle Freelists > *Subject:* RE: Move to new hardware and upgrade o/s > > > > Hi Kumar, we do something similar to what you are discussing. When I hav= e > a new server that will re place an old server here is what we do. Assume > old server is named **svrprd**. > > > > 1) Build new server and name it svrprdnew (ip is not important at > this point). > > 2) Install all necessary software (oracle, agents, etc.) > > a. In this case I would install both the same oracle version as on > svrprd and the new version in a different oracle home > > 3) Also, prepare filesystems as you have stated. > > > > Now come the maintenance window to put new server into service. It takes > me about 45 minutes on average, but we have the ability to be down on > weekends. > > > > 4) Move databases from srvprd to svrprdold > > 5) Rename svrprd to srvprdold and give it a new ip address. Restart > network. > > 6) Rename svrprdnew to srvprd and give it the proper ip address so > it is the same as original srvprd server. Reboot. > > > > At this time, when the new srvprd server is finished with the reboot > nobody in the organization should even realize the hardware changed. All > host names and ip addresses are as they were originally. > > > > When the appropriate time arrives to upgrade the databases you will > already have the new oracle home ready for the upgrade. > > > > I hope this helps and I=E2=80=99m sorry I don=E2=80=99t use ASM so I can= =E2=80=99t offer help in > that area, but I would suppose that should work fine. > > > > *Michael Cunningham* > *Senior Database Administrator* > *The Doctors' Company* > 707.226.0221 - desk > 707.337.0184 - cell > > > > *From:* oracle-l-bounce@freelists.org [ > mailto:oracle-l-bounce@freelists.org ] *On > Behalf Of *Kumar Madduri > *Sent:* Friday, June 06, 2014 10:24 AM > *To:* oracle Freelists > *Subject:* Move to new hardware and upgrade o/s > > > > I am working on moving the current boxes to new ones and upgrade to > 11.2.0.4 > > The original idea was to do this. > > Install software and move the databases one by one. Create new firewall > rules for this because host name and ip change. > > > > But another thing came to mind since we have firewalls and I would have t= o > redefine new firewall rules > > > > 1. Get new box with new hostname. > > 2. Install 11.2.0.4 Grid, 11.2.0.2 rdbms, 11.2.0.4 rdbms. > > 3. All our development, int environments are on NAS. So the same storage > can be mounted on new boxes > > 4. When ready to cut over, shutdown old development box; bring up new box= ; > re-ip the new box to have same ip address as old box (still keep the new > host name. Just change ip address to old one). > > 5. Tell asm on new box about the new databases (alter system set > asm_diskstring =3D'''''). > > 6. Bring up the databases > > 7. Do the upgrade when developers are ok (one by one since we have more > than one database on the same box in dev and int) > > The advantange in this method is > > 1. We move all databases in one shot from old to new. > > 2. We can upgrade to 11.2.0.4 one after other > > 3. Most important, I think is we dont have to worry about firewall rules > because we are getting same ip address back. > > > > The one issue I think in this approach is > > Since we use oracle apps, fnd_nodes would not be updated with the new > database server name till we run autoconfig again (thiss would be done as > part of 11.2.0.4 upgrade). Till then the topology would be out of sync. B= ut > we have not really enabled 'autoconfig' on our database server. So even > though topology would be out of sync (temporarily),l am thinking we would > be ok since tnsnames would be updated manually for those environments tha= t > are not upgraded. > > > > Do you see any issues or is there a better way to accomplish the same ? > The reason I think about this approach is I wanted to avoid redefining al= l > the firewall rules if I can (with change in IP) and I can decommision the > old box relatively earlier once I am done with the move and it is stable > for couple of weeks. > > > > > > Thank you > > Kumar > > > > *Confidentiality Notice*: This message and any attachments hereto may > contain confidential and privileged communications or information and/or > attorney client communications or work-product protected by law. The > information contained herein is transmitted for the sole use of the > intended recipient(s). If you are not the intended recipient or designate= d > agent of the recipient of such information, you are hereby notified that > any use, dissemination, copying or retention of this e-mail or the > information contained herein is strictly prohibited and may subject you t= o > penalties under federal and/or state law. If you received this e-mail in > error, please notify the sender immediately and permanently delete this > e-mail. > --089e014953ec44dd3e04fb2f4014 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

When I did this the sysadmin installed the new server and ca= lled it oracle01a. We had all the database files on LUNs. We swapped the LU= NS over to the new server and then renamed the old server to Oracle01b and = the new one to Oracle01.
We had to wait a little while for the changes to synchronise across the who= le network, but we didn't have to change any tnsnames.

On 6 Jun 2014 18:59, "Scott Canaan" &l= t;srcdco@rit.edu> wrote:

If all you are concerned = about is pointing to the new server, then use DNS and make the change there= .=C2=A0 That way the users won=E2=80=99t even know the server changed IPs and the DNS alias would handle that.=C2=A0 That=E2=80=99s the way we h= andle moves from one server to another.

We use impdp over the net= work to move the data over.

=C2=A0

Scott Canaan =E2=80=9988 = (srcdco@rit.edu)

(585) 475-7886 =E2= =80=93 work=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 (585) 339-8659 =E2=80=93 cell

=E2=80=9CLife is like a s= ewer, what you get out of it depends on what you put into it.=E2=80=9D =E2= =80=93 Tom Lehrer

=C2=A0

From: oracle-l-bounce= @freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Cunningham, Mike
Sent: Friday, June 06, 2014 1:41 PM
To: ksmaddu= ri@gmail.com; oracle Freelists
Subject: RE: Move to new hardware and upgrade o/s

=C2=A0

Hi Kumar, we do something= similar to what you are discussing.=C2=A0 When I have a new server that wi= ll re place an old server here is what we do.=C2=A0 Assume old server is named *svrprd*.

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Build new server and= name it svrprdnew (ip is not important at this point).

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Install all necessar= y software (oracle, agents, etc.)

a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In this case I would= install both the same oracle version as on svrprd and the new version in a= different oracle home

3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Also, prepare filesy= stems as you have stated.

=C2=A0

Now come the maintenance window to put new se= rver into service.=C2=A0 It takes me about 45 minutes on average, but we ha= ve the ability to be down on weekends.

=C2=A0

4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Move databases from = srvprd to svrprdold

5)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rename svrprd to srv= prdold and give it a new ip address.=C2=A0 Restart network.

6)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Rename svrprdnew to = srvprd and give it the proper ip address so it is the same as original srvp= rd server.=C2=A0 Reboot.

=C2=A0

At this time, when the new srvprd server is finished with the reboot nob= ody in the organization should even realize the hardware changed.=C2=A0 All host names and ip addresses are as they were originally.=

=C2=A0

When the appropriate time arrives to upgrade the databases you will alre= ady have the new oracle home ready for the upgrade.

=C2=A0

I hope this helps and I=E2=80=99m sorry I don=E2=80=99t use ASM so I can= =E2=80=99t offer help in that area, but I would suppose that should work fi= ne.

=C2=A0

Michael Cunningham=
Senior Database Administrator
The Doctors' Company
707.226.0221 - desk
707.3= 37.0184 - cell

=C2=A0

From: oracle-l= -bounce@freelists.org [mailto:oracle-l-bounce@freelists.org] On Behalf Of Kumar Madduri
Sent: Friday, June 06, 2014 10:24 AM
To: oracle Freelists
Subject: Move to new hardware and upgrade o/s

=C2=A0

I am working on moving the current boxes to new ones= and upgrade to 11.2.0.4

The original idea was to do this.

Install software and move the databases one by one. = =C2=A0Create new firewall rules for this because host name and ip change.

=C2=A0

But another thing came to mind since we have firewal= ls and I would have to redefine new firewall rules=C2=A0

=C2=A0

1. Get new box with new hostname.

2. Install 11.2.0.4 Grid, 11.2.0.2 rdbms, 11.2.0.4 r= dbms.

3. All our development, int environments are on NAS.= So the same storage can be mounted on new boxes =C2=A0

4. When ready to cut over, shutdown old development = box; bring up new box; re-ip the new box to have same ip address as old box= (still keep the new host name. Just change ip address to old one).<= u>

5. Tell asm on new box about the new databases (alte= r system set asm_diskstring =3D''''').

6. Bring up the databases

7. Do the upgrade when developers are ok (one by one= since we have more than one database on the same box in dev and int)

The advantange in this method is

1. We move all databases in one shot from old to new= .

2. We can upgrade to 11.2.0.4 one after other =C2=A0=

3. Most important, I think is we dont have to worry = about firewall rules because we are getting same ip address back.=

=C2=A0

The one issue I think in this approach is<= /u>

Since we use oracle apps, fnd_nodes would not be upd= ated with the new database server name till we run autoconfig again (thiss = would be done as part of 11.2.0.4 upgrade). Till then the topology would be= out of sync. But we have not really enabled 'autoconfig' on our database server. So even though topolo= gy would be out of sync (temporarily),l am thinking we would be ok since tn= snames would be updated manually for those environments that are not upgrad= ed.

=C2=A0

Do you see any issues or is there a better way to ac= complish the same ? The reason I think about this approach is I wanted to a= void redefining all the firewall rules if I can (with change in IP) and I c= an decommision the old box relatively earlier once I am done with the move and it is stable for couple of weeks.=

=C2=A0

=C2=A0

Thank you

Kumar

=C2=A0

Confidentiality Notic= e: This message and any attachments hereto may contain confidential and privi= leged communications or information and/or attorney client communications o= r work-product protected by law. The information contained herein is transm= itted for the sole use of the intended recipient(s). If you are not the intended recipient or designated agent of= the recipient of such information, you are hereby notified that any use, d= issemination, copying or retention of this e-mail or the information contai= ned herein is strictly prohibited and may subject you to penalties under federal and/or state law. If you re= ceived this e-mail in error, please notify the sender immediately and perma= nently delete this e-mail.

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