Thread

  1. Oracle to postgres migration

    Daulat Ram <daulat.ram@exponential.com> — 2019-04-08T10:23:40Z

    Hi team,
    
    Please confirm ! Can we migrate Oracle 12c database (12.1.0.1.0) running on Solaris to PostgreSQL 11.2 on  Linux (Ubuntu). Also, please suggest the tools and pre-requisites.
    
    Regards,
    Daulat
    
    
    
  2. Re: Oracle to postgres migration

    Julien Rouhaud <rjuju123@gmail.com> — 2019-04-08T12:04:01Z

    On Mon, Apr 8, 2019 at 1:49 PM Daulat Ram <Daulat.Ram@exponential.com> wrote:
    >
    > Please confirm ! Can we migrate Oracle 12c database (12.1.0.1.0) running on Solaris to PostgreSQL 11.2 on  Linux (Ubuntu). Also, please suggest the tools and pre-requisites.
    A database migration is likely feasible, but might require quite a lot
    of work depending on what features you're using, and the amount of PL
    code.  Also, obviously migrating the database is only a part of the
    overall migration process, as you'll also need to take care of the
    application(s), the backup/restore, monitoring and all other tools you
    need.
    
    Concerning the database migration, the best tool is probably Gilles
    Darold's ora2pg.  The tool also provides a migration cost assessment
    report, to evaluate the difficulty of the database migration.  More
    information on http://ora2pg.darold.net/
    
    
    
    
  3. Re: Oracle to postgres migration

    Rick Otten <rottenwindfish@gmail.com> — 2019-04-08T12:24:39Z

    On Mon, Apr 8, 2019 at 8:04 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
    
    > On Mon, Apr 8, 2019 at 1:49 PM Daulat Ram <Daulat.Ram@exponential.com>
    > wrote:
    > >
    > > Please confirm ! Can we migrate Oracle 12c database (12.1.0.1.0) running
    > on Solaris to PostgreSQL 11.2 on  Linux (Ubuntu). Also, please suggest the
    > tools and pre-requisites.
    > A database migration is likely feasible, but might require quite a lot
    > of work depending on what features you're using, and the amount of PL
    > code.  Also, obviously migrating the database is only a part of the
    > overall migration process, as you'll also need to take care of the
    > application(s), the backup/restore, monitoring and all other tools you
    > need.
    >
    > Concerning the database migration, the best tool is probably Gilles
    > Darold's ora2pg.  The tool also provides a migration cost assessment
    > report, to evaluate the difficulty of the database migration.  More
    > information on http://ora2pg.darold.net/
    >
    >
    >
    The last big Oracle to PG migration that I did was several years ago.  We
    stood up the PostgreSQL instance(s) and then used SymmetricDS to
    synchronize the Oracle and PG databases.   After tuning and testing the
    postgresql side, we cut over the applications live - with minimal downtime
    - by releasing the updated application code and configuration.   If we
    needed to fail back, it was also pretty easy to undo the release and
    configuration changes.
    
    Another approach you can play with is to leverage Foreign Data Wrappers.
    In that scenario, you can run queries on your Oracle database from within
    PostgreSQL.  You can use those queries to copy data directly into new
    tables without any interim files, or as a hybrid transition while you get
    the new database set up.
    
    At the time I was working on that migration, we had too many
    data-edge-cases for ora2pg to be very useful.  It has come a long ways
    since then.  I'm not sure it can do a live cutover, so you may need to plan
    a bit of downtime if you have a lot of data to move into the new database.
    
    Note that you will also almost certainly want to use a connection pooler
    like PGBouncer and/or PGPool II (or both at the same time), so be sure to
    include that in your plans from the beginning.
    
    That said, none of this is on topic for the performance mailing list.
    Please try to direct your questions to the right group next time.
    
  4. Re: Oracle to postgres migration

    phb07 <phb07@apra.asso.fr> — 2019-04-08T17:45:32Z

    Le 08/04/2019 à 14:24, Rick Otten a écrit :
    >
    >
    > On Mon, Apr 8, 2019 at 8:04 AM Julien Rouhaud <rjuju123@gmail.com 
    > <mailto:rjuju123@gmail.com>> wrote:
    >
    >     On Mon, Apr 8, 2019 at 1:49 PM Daulat Ram
    >     <Daulat.Ram@exponential.com <mailto:Daulat.Ram@exponential.com>>
    >     wrote:
    >     >
    >     > Please confirm ! Can we migrate Oracle 12c database (12.1.0.1.0)
    >     running on Solaris to PostgreSQL 11.2 on  Linux (Ubuntu). Also,
    >     please suggest the tools and pre-requisites.
    >     A database migration is likely feasible, but might require quite a lot
    >     of work depending on what features you're using, and the amount of PL
    >     code.  Also, obviously migrating the database is only a part of the
    >     overall migration process, as you'll also need to take care of the
    >     application(s), the backup/restore, monitoring and all other tools you
    >     need.
    >
    >     Concerning the database migration, the best tool is probably Gilles
    >     Darold's ora2pg.  The tool also provides a migration cost assessment
    >     report, to evaluate the difficulty of the database migration.  More
    >     information on http://ora2pg.darold.net/
    >
    >
    >
    > The last big Oracle to PG migration that I did was several years ago.  
    > We stood up the PostgreSQL instance(s) and then used SymmetricDS to 
    > synchronize the Oracle and PG databases.   After tuning and testing 
    > the postgresql side, we cut over the applications live - with minimal 
    > downtime - by releasing the updated application code and 
    > configuration.   If we needed to fail back, it was also pretty easy to 
    > undo the release and configuration changes.
    >
    > Another approach you can play with is to leverage Foreign Data 
    > Wrappers.  In that scenario, you can run queries on your Oracle 
    > database from within PostgreSQL.  You can use those queries to copy 
    > data directly into new tables without any interim files, or as a 
    > hybrid transition while you get the new database set up.
    >
    > At the time I was working on that migration, we had too many 
    > data-edge-cases for ora2pg to be very useful.  It has come a long ways 
    > since then.  I'm not sure it can do a live cutover, so you may need to 
    > plan a bit of downtime if you have a lot of data to move into the new 
    > database.
    >
    > Note that you will also almost certainly want to use a connection 
    > pooler like PGBouncer and/or PGPool II (or both at the same time), so 
    > be sure to include that in your plans from the beginning.
    >
    > That said, none of this is on topic for the performance mailing list.  
    > Please try to direct your questions to the right group next time.
    >
    Just a few additional pieces of information.
    1) migration from one DBMS to another must always be lead as a project 
    (because your data are always important ;-)
    2) a migration project always has the following main tasks:
    - setting a proper postgres platform (with all softwares, procedures and 
    documentation needed to provide a good PostgreSQL service to your 
    applications/clients) (you may already have such a platform).
    - migrating the data. This concerns both the structure (DDL) and the 
    data content.
    - migration the stored procedures, if any. In Oracle migrations, this is 
    often a big workload in the project.
    - adapting the client application. The needed effort here can be huge or 
    ... null, depending on the used languages, whether the data access API 
    are compatible or whether an ORM is used.
    - when all this has been prepared, a test phase can start. This is very 
    often the most costly part of the project, in particular for mission 
    critical databases.
    - then, you are ready to switch to Postgres.
    3) do not hesitate to invest in education and external professional support.
    4) before launching such a project, it is highly recommended to perform 
    a preliminary study. For this purpose, as Julien said, ora2pg brings a 
    big help in analysing the Oracle database content. The cost estimates 
    are pretty well computed, which gives you very quickly an idea of the 
    global cost of the database migration. For the application side, you may 
    also have a look at code2pg.
    
    KR. Philippe.
    
  5. Re: Oracle to postgres migration

    legrand legrand <legrand_legrand@hotmail.com> — 2019-04-08T20:02:36Z

    Rick Otten-2 wrote
    > On Mon, Apr 8, 2019 at 8:04 AM Julien Rouhaud &lt;
    
    > rjuju123@
    
    > &gt; wrote:
    > 
    > [...]
    > 
    > That said, none of this is on topic for the performance mailing list.
    > Please try to direct your questions to the right group next time.
    
    Is "general" the correct one ?
    or should a "migration" group be created ;^> 
    
    Regards
    PAscal
    
    
    
    --
    Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html
    
    
    
    
  6. Re: Oracle to postgres migration

    Gavin Flower <gavinflower@archidevsys.co.nz> — 2019-04-08T22:31:15Z

    On 09/04/2019 08:02, legrand legrand wrote:
    > Rick Otten-2 wrote
    >> On Mon, Apr 8, 2019 at 8:04 AM Julien Rouhaud &lt;
    >> rjuju123@
    >> &gt; wrote:
    >>
    >> [...]
    >>
    >> That said, none of this is on topic for the performance mailing list.
    >> Please try to direct your questions to the right group next time.
    > Is "general" the correct one ?
    > or should a "migration" group be created ;^>
    >
    > Regards
    > PAscal
    >
    >
    >
    > --
    > Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html
    >
    >
    I think having a specific migration group would also be likely to 
    improve the visibility of pg, and the idea of migrating to pg.  As it 
    help pg to appear in more search results.
    
    
    Cheers,
    Gavin
    
    
    
    
    
    
  7. Re: Oracle to postgres migration

    David G. Johnston <david.g.johnston@gmail.com> — 2019-04-08T22:42:57Z

    On Mon, Apr 8, 2019 at 3:31 PM Gavin Flower <GavinFlower@archidevsys.co.nz>
    wrote:
    
    > I think having a specific migration group would also be likely to
    > improve the visibility of pg, and the idea of migrating to pg.  As it
    > help pg to appear in more search results.
    >
    >
    I presently have qualms retaining novice, sql, performance, and probably
    some others.  I don't think adding yet another specialized low-volume list
    is of particular benefit.  Nor do I think it behooves the core project to
    be in the center of migration support anyway.
    
    This discussion can and should be moved to -general
    
    David J.