Move Production Database Engine to Dedicated DB Server

 4 Replies
 0 Subscribed to this topic
 27 Subscribed to this forum
Sort:
Author
Messages
Tom Whalen
New Member
Posts: 1
New Member

    background:  AIX 5.3, Oracle 10gR2 (10.2.0.4), LSF9 (9.0.0.4)

    What we need to do is to move our Lawson application server's Oracle services from it's current location to a new dedicated server called LAWDB.  I've already created the server, installed Oracle, created the lawson production tablespaces, migrated a copy of the Oracle data from the production system to the new LAWDB tablespaces, (DATA, INDEX, GEN, LOGAN) for both production and a test set of tablespaces. 

    My question is I know that I'll need to modify the ORACLE files in the various productlines (prodline, gen, and logan) to point to the new tablespaces names and logins, etc, etc.  But what else is necessary to have the production and test app servers be able to connect to the new dedicated DB server?  Does the test and production app server need a Oracle Client service running using the TNSname of the dedicated DB server?  Is there any setting inside the ORACLE files the is needed to point to this remote servers?  Does anyone have any tips to what to look out for?  Overall I think I have the bulk of the work covered I just have a couple of knowledge gaps I need to fill in.

    Thanks in Advance...Tom

     

    Ben Coonfield
    Veteran Member
    Posts: 146
    Veteran Member
      You will need the Oracle client to be installed, but it sounds like you aready do. There isn't a process you need to start on the client side. There is a listener process that has to be running, but that will be on the database server.

      You will need to make sure tnsnames.ora, and perhaps sqlnet.ora are configured correctly. I would first start by making sure sqlplus is installed on the Lawson application server, and make sure you can connect to the remote database from sqlplus. If not, you need to check your tnsnames.ora, sqlnet.ora, and the listener on the database server. If you can connect from sqlplus, then the only thing you need to do is make sure that ORACLE_HOME is set correctly and the ORACLE files are updated with the right parameters.
      John Henley
      Posts: 3353
        BTW, I've never been a big fan of separating the database server from Lawson apps. The way Lawson's database layer is designed causes much worse performance for certain types of processes.
        Thanks for using the LawsonGuru.com forums!
        John
        John Costa
        Veteran Member
        Posts: 154
        Veteran Member

          I would like to echo John's comments about separating the applications from the database.  Prior to going to LSF9, we had the Lawson databases (SQL-Server) on the same box as the applications.  It was only the web services (TomCat) that were off on their own server.

          Since going to LSF9, we've moved the applications and web services (IBM WebSphere) to one server and the databases (SQL-Server 2005) to their own dedicated server.  Since these are brand new servers with 16gb or RAM each, tons of disk space, four dual-core CPUs, etc., we expected great performance improvements.

          Unfortunately, that is not so.  Although some of the less resource-intensive jobs complete quicker, we've found that the big jobs that hit large tables are taking as much as three times longer than they did before and we are having to adjust various job schedules to accomodate the system slowdowns.  We haven't been able to definitively find what has caused the slowdowns but we're thinking it's due to network latency between the two servers.

          We listened to Lawson and put WebSphere and the apps on one box and the databases on another and we are now starting to question the integrity of that decision.

          _________________ John - Wichita, KS
          Ben Coonfield
          Veteran Member
          Posts: 146
          Veteran Member
            Posted By John Costa on 05/20/2009 03:42 PM

            Although some of the less resource-intensive jobs complete quicker, we've found that the big jobs that hit large tables are taking as much as three times longer than they did before ...

             

            I also have reservations about moving the production database to a remote database server.  We experienced a significant increase in job run time due to running the database remotely, averaging perhaps about 20%.