Results 1 to 9 of 9

Thread: SQL Server Always On Availability Groups

  1. #1

    SQL Server Always On Availability Groups

    Has anyone tried configuring E1 using SQL Server Always On Availability Groups (AOAG)?

    The official line from Oracle is that it is not supported yet – because they have not tested it. (It was only released five years ago!)
    But we cannot see why it should not work.
    Perhaps we would have to avoid configuring a listener (although it would be nice if it worked) – but we can see no reason why the standard “database mirroring” and manual failover functionality within AOAG would not work; the CNC configuration and JDE middleware would surely be unaware that AOAG was configured beneath the covers?

    (We are currently in the design process of a new installation of E1 9.2 on either SQL 2014 or SQL 2016 – and AOAG offers by far the best options for HA, DR and real-time reporting.)

  2. #2
    Reviving this thread because I have the same question.

    Glenn, did you end up using E1 with SQL Server AOAG?

    Does anyone else have any experiences to share on this topic?

    Thanks in advance
    EnterpriseOne Xe to 9.2
    Windows/ Unix / AS400
    Oracle , SQL Server, DB2
    WAS , WLS
    AppWorx, Tidal , SmartScheduler

  3. #3
    Quote Originally Posted by ice_cube210 View Post
    Reviving this thread because I have the same question.

    Glenn, did you end up using E1 with SQL Server AOAG?

    Does anyone else have any experiences to share on this topic?

    Thanks in advance
    What do you need to know?

    We can spend weeks on this topic if you wish.

  4. #4
    Hi Jeff,

    That is true, it is a vast topic. I guess I am just looking to understand if the overall experience was positive or negative.
    Any overheads on performance and lastly how E1 was impacted during a failover.

    Thanks
    EnterpriseOne Xe to 9.2
    Windows/ Unix / AS400
    Oracle , SQL Server, DB2
    WAS , WLS
    AppWorx, Tidal , SmartScheduler

  5. #5
    Quote Originally Posted by ice_cube210 View Post
    Hi Jeff,

    That is true, it is a vast topic. I guess I am just looking to understand if the overall experience was positive or negative.
    Any overheads on performance and lastly how E1 was impacted during a failover.

    Thanks
    From an E1 perspective it is pretty normal - one creates a listener and E1 connects to that like any other data source.

    Beware that the lure of the 'readable' secondary is dangerous. It seems like a great way to offload queries onto the 'non-active' server but in fact, running queries against the secondary in an AG is not similar to running queries against a replication target server. The two nodes in an AG are intimately connected and the negative impact on the secondary can adversely affect the primary.

    Index maintenance on large databases is an absolute nightmare. Since an AG mirrors the transactions to the secondary, index maintenance transactions have to be 'replayed' on the secondary, across a wire (LAN for local secondaries, WAN for off-prem secondaries). Imagine transferring 1TB of index rebuild transactions every weekend. It'll take hours for even your local secondary to catch up, days for a slow WAN remote secondary.

    You better super-optimize your tempdb because AG mirroring uses Snapshot Isolation, which uses the Version Store, which uses tempdb. IO measurements are through the roof, particularly if you are also utilizing RCSI, which you should be. Be ready to do at least 20,000 IOPS on your data and tempdb drives. Transaction log sizes are going to be large for a whole bunch of very detailed reasons.

    Back to readable secondaries - everyone will want to read from your 'readable' secondary. Some software does not do a good job of closing SQL connections. This will wreak havoc on your primary. You've been warned.

    Thoughts:

    Hard to administer but darn nice to have another live copy of your data.

    E1 still cannot handle a failover.


    Let me know if you have any more specific questions.

  6. #6
    Hi Jeff, Thank you very much for your insightful response.
    EnterpriseOne Xe to 9.2
    Windows/ Unix / AS400
    Oracle , SQL Server, DB2
    WAS , WLS
    AppWorx, Tidal , SmartScheduler

  7. #7
    Quote Originally Posted by ice_cube210 View Post
    Hi Jeff,

    That is true, it is a vast topic. I guess I am just looking to understand if the overall experience was positive or negative.
    Any overheads on performance and lastly how E1 was impacted during a failover.

    Thanks
    I work on an environment that has a clustered MSSQL Server 2014 with AOAG and made availible to EnterpriseOne via logical name, so E1 doesn't know which node it's using. Works like a charm, Enterprise Server sometimes doesn't even notice a failover!

  8. #8
    Quote Originally Posted by schojo44 View Post
    I work on an environment that has a clustered MSSQL Server 2014 with AOAG and made availible to EnterpriseOne via logical name, so E1 doesn't know which node it's using. Works like a charm, Enterprise Server sometimes doesn't even notice a failover!
    Curious how you set it up so that it works like this.

  9. #9
    Quote Originally Posted by brother_of_karamazov View Post
    Curious how you set it up so that it works like this.
    we actually even did - we only got this database server to work with and it does very well!
    if you need details i'm pretty sure i can get them
    EnterpriseOne 8.12 to 9.2
    AIX, Linux, Windows, IBM i
    Oracle DB, MSSQL, DB2
    WAS, WLS

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
The legal restrictions and terms of use applicable to this site are available here.
Use of this site signifies your agreement to the terms of use.
JDELIST is NOT affiliated with JD Edwards® & Company, Oracle or Peoplesoft. Contents of this site are neither endorsed nor approved by JD Edwards® & Company and, or Oracle.