[IQUG] IQUG Digest, Vol 56, Issue 6

Steve Shen sshen at sscinc.com
Wed Aug 9 10:49:55 MST 2017


Hi Mark,

I am hoping to have a chance in testing this.  Thank you again.

Kind regards,
Steve Shen

From: Mark Mumy [mailto:markdmumy at gmail.com]
Sent: Wednesday, August 09, 2017 12:28 PM
To: Steve Shen
Cc: Mark Mumy; Chris Baker; iqug at iqug.org
Subject: Re: [IQUG] IQUG Digest, Vol 56, Issue 6

To enable RLV on the node, you simply need to run the ALTER MULTIPLEX SERVER…ENABLE RLV STORE.  According to engineering, that will disable RLV on the failed coordinator and enable the current coordinator for RLV.  This still then stop the new coordinator so you will have to restart it.  Remember RLV is enabled at startup based on the devices and options.  More importantly, the RLV enabled or disabled is read only at startup in multiplex from the system tables.  During a CN failover, the tables show the old server as being the RLV server.  You must manually intervene and make sure that the new CN knows that it will now do RLV work from this point forward.

Mark

On Aug 9, 2017, at 10:44, Steve Shen <sshen at sscinc.com<mailto:sshen at sscinc.com>> wrote:

Hi Mark,

Your explanation today made sense; otherwise the RLV feature for those RLV-enabled tables would not be working after the DR failover, planned or unplanned.

So my educated guess from yesterday was correct : It's better to use the RLV storage like IQ_SYSTEM_MAIN and user_main database spaces due to the goal of migrating a Simplex to an Multiplex.  They should be global and visible to all the nodes that participate in the Multiplex.

I also believe that those nodes in the Multiplex have to have the identical physical path to the RLV storage.

Can you elaborate "Enable RLV on the new coordinator" after the DR failover?

Did it include the following two tasks?
1. To create RLV database space at the new coordinator node after the DR failover?
2. To re-enable RLV for the same set of tables from the old coordinator after the DR failover?

Theoretically the IQ DBA should not have to do these two tasks because I do not think that we will have to do the same tasks to IQ_SYSTEM_MAIN and user_main after a DR failover, right?

Ideally the RLV storage and all the RLV-enabled tables should be transparent to the IQ DBA after a DR failover.  There should not be any manual effort to recover anything because nothing was lost.  I am sharing my doubts with you.

Thank you.

Kind regards,

Steve Shen

t: (646) 827-2102

-----Original Message-----
From: Mumy, Mark [mailto:mark.mumy at sap.com]
Sent: Wednesday, August 09, 2017 10:55 AM
To: Steve Shen; Baker, Chris; iqug at iqug.org<mailto:iqug at iqug.org>
Subject: Re: [IQUG] IQUG Digest, Vol 56, Issue 6

The cache is not needed during failover.  Weird, right?  IQ RLV leverages the same technology as SAP HANA in this respect.  When data is written to cache, we will burst that memory chunk to disk in the RLV dbspace.  This guarantees that the data is safeguarded on disk before the transaction commits so that we have full data integrity and transactional protection should the machine or IQ be halted for any reason.

Here’s a basic process that we should follow if we want RLV to be able to participate in failover:

RLV store must be mounted on the coordinator and the designated failover node via a shared mechanism like we would use for system main and user main.
When the secondary node takes on the coordinator role, it recovers the RLV and applies the changes.
Enable RLV on the new coordinator.  This implicitly disables on the pre-failover coordinator and enables it on the failover node.
The failover coordinator will restart and on the restart the committed data in the rlv dbspace will be recovered into memory.

The change to previous emails is the first item.  For simplex and non-failover we don’t much care where the RLV store is located as it is isolated to being used on a single node.  In order to have RLV enabled in a multiplex, we want the RLV store to be created in the same way that we would the system main or your user main(s).  That is, the RLV store must be present on all nodes so that you can failover to any node you specify as the secondary coordinator.

Mark


Mark Mumy

Strategic Technology Incubation Group
Customer Innovation and Enterprise Platform |  SAP

M +1 347-820-2136 | E mark.mumy at sap.com<mailto:mark.mumy at sap.com>

My Blogs: https://blogs.sap.com/author/markmumy/



https://sap.na.pgiconnect.com/I825063

Conference tel: 18663127353,,8035340905#




On 8/9/17, 06:50, "Steve Shen" <sshen at sscinc.com<mailto:sshen at sscinc.com>> wrote:

   Hi Chris, Mark and all,

   Good morning!

   We had some tables that our clients required concurrent updates like what we have been doing in ASE tables & OLTP functions.

   Based on Mark and your explanation they should be able to update the same tables from the coordinator after the Simplex is migrated to the Multiplex; but I still had doubts: What would happen to the RLV enabled tables capability or feature after an unexpected DR failover because the new coordinator did not have RLV database space and cache.

   Thank you.

   Regards,

   Steve Shen

   -----Original Message-----
   From: Baker, Chris [mailto:c.baker at sap.com]
   Sent: Tuesday, August 08, 2017 4:47 PM
   To: Mumy, Mark; Steve Shen; iqug at iqug.org<mailto:iqug at iqug.org>
   Subject: RE: [IQUG] IQUG Digest, Vol 56, Issue 6

   Steve,

   I am not sure where you see this in the docs either.  The 'Shared Store Path Requirement' in the docs (https://help.sap.com/viewer/a8986af484f21015b55bed80129dc962/16.1.2.0/en-US/a4c8896184f2101592c2fd5507f3312e.html) only mentions IQ_SYSTEM_MAIN and any other user dbpaces (that are part of the main store) must be shared RW.  Not the RLV store.

   I cannot state that RLV is supported in IQ Multiplex beyond what the documentation already says.  Only the coordinator can perform write operations on an RLV-enabled table while other nodes can only read the table.  To state otherwise would imply that RW operations are supported on all nodes of the multiplex for RLV-enabled tables - which is incorrect.  Non RLV-enabled tables can, of course, be used in RW operations across the multiplex, per normal multiplex operations.  Once a table is RLV-enabled, however, it can only be written by the co-ordinator.

   What are you expecting to accomplish over normal IQ capabilities by using RLV?  Are you performing concurrent operations where multiple clients must change the table at the same time?

   Chris

   Chris Baker | Database Engineering Evangelist | CERT | PI HANA Platform Data Management | SAP T +1 416-226-7033 | M +1 647-224-2033 | TF +1 866-716-8860 SAP Canada Inc. 445 Wes Graham Way, Waterloo, N2L 6R2 c.baker at sap.com<mailto:c.baker at sap.com> | www.sap.com<http://www.sap.com>

   https://sap.na.pgiconnect.com/I826572
   Conference tel: 1-866-312-7353,,9648565377#

   -----Original Message-----
   From: Mumy, Mark
   Sent: Tuesday, August 8, 2017 4:30 PM
   To: Steve Shen <sshen at sscinc.com<mailto:sshen at sscinc.com>>; Baker, Chris <c.baker at sap.com<mailto:c.baker at sap.com>>; iqug at iqug.org<mailto:iqug at iqug.org>
   Subject: Re: [IQUG] IQUG Digest, Vol 56, Issue 6

   The RLV store and cache are only on the coordinator.  Not sure where it says that the dbspaces must be on all nodes.  All other nodes will communicate back to the coordinator to get the data in the RLV store, they don’t read the cache or store directly.

   Mark


   Mark Mumy

   Strategic Technology Incubation Group
   Customer Innovation and Enterprise Platform |  SAP

   M +1 347-820-2136 | E mark.mumy at sap.com<mailto:mark.mumy at sap.com>

   My Blogs: https://blogs.sap.com/author/markmumy/



   https://sap.na.pgiconnect.com/I825063

   Conference tel: 18663127353,,8035340905#




   On 8/8/17, 15:14, "iqug-bounces at iqug.org<mailto:iqug-bounces at iqug.org> on behalf of Steve Shen" <iqug-bounces at iqug.org<mailto:iqug-bounces at iqug.org> on behalf of sshen at sscinc.com<mailto:sshen at sscinc.com>> wrote:

       Hi Chris,

       Based on the docs the RLV database space needs to be mounted to all the nodes participating in the IQ Multiplex. I am assuming that this should also be a Raw Partition in Solaris X64 or Linux or a NFS in Linux.

       Based on the docs since we can modify multiple rows on the same page from the coordinator, I would say that "RLV is supported in the IQ version 16.0 SP11 Multiplex".

       Do you agree these statements?  Thank you.

       Regards,

       Steve Shen

       -----Original Message-----
       From: Baker, Chris [mailto:c.baker at sap.com]
       Sent: Tuesday, August 08, 2017 3:40 PM
       To: Steve Shen; iqug at iqug.org<mailto:iqug at iqug.org>
       Subject: RE: IQUG Digest, Vol 56, Issue 6

       The docs for 16.0 SP 11 up to current (16.1 SP2 - https://help.sap.com/viewer/a893406f84f21015b779cc846d759839/16.1.2.0/en-US/a48d34c384f21015b011f0f51675f658.html) have the following statement:

       In-Memory Row-Level Versioning in a Multiplex

       The RLV store can only be enabled on the coordinator, making it the RLV writer. All other nodes in a multiplex are considered RLV readers.

       On the RLV writer, you can execute DDL, DML, and query data. On RLV readers, data in RLV-enabled tables is available to queries, but modification of data and schema are not allowed.

       Chris

       Chris Baker | Database Engineering Evangelist | CERT | PI HANA Platform Data Management | SAP T +1 416-226-7033 | M +1 647-224-2033 | TF +1 866-716-8860 SAP Canada Inc. 445 Wes Graham Way, Waterloo, N2L 6R2 c.baker at sap.com<mailto:c.baker at sap.com> | www.sap.com<http://www.sap.com>

       https://sap.na.pgiconnect.com/I826572
       Conference tel: 1-866-312-7353,,9648565377#

       -----Original Message-----
       From: iqug-bounces at iqug.org<mailto:iqug-bounces at iqug.org> [mailto:iqug-bounces at iqug.org] On Behalf Of Steve Shen
       Sent: Tuesday, August 8, 2017 3:13 PM
       To: iqug at iqug.org<mailto:iqug at iqug.org>
       Subject: [IQUG] IQUG Digest, Vol 56, Issue 6

       Hello all,

       As of April 2013 RLV (Row Level Versioning) was not available or supported in IQ Multiplex based on the Internet Link below:

       https://archive.sap.com/discussions/thread/3332052

       Was it still not supported at IQ version 15.4 and 16 Multiplex today?

       Please let me know if you have any insight into this.  Thank you.

       Kind regards,

       Steve Shen
       This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.
       _______________________________________________
       IQUG mailing list
       IQUG at iqug.org<mailto:IQUG at iqug.org>
       http://iqug.org/mailman/listinfo/iqug
       This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.
       _______________________________________________
       IQUG mailing list
       IQUG at iqug.org<mailto:IQUG at iqug.org>
       http://iqug.org/mailman/listinfo/iqug


   This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.


This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.
_______________________________________________
IQUG mailing list
IQUG at iqug.org<mailto:IQUG at iqug.org>
http://iqug.org/mailman/listinfo/iqug

This email with all information contained herein or attached hereto may contain confidential and/or privileged information intended for the addressee(s) only. If you have received this email in error, please contact the sender and immediately delete this email in its entirety and any attachments thereto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://iqug.org/pipermail/iqug/attachments/20170809/062e7936/attachment-0001.html>


More information about the IQUG mailing list