[IQUG] Cannot secondary server in an IQ Multiplex

Jason Froebe jason.froebe at gmail.com
Mon Jun 25 14:15:47 MST 2018


How about:


alter multiplex server prod_node2 rename "dev_node2" host "devbox2" port 
20000

alter multiplex server prod_node3 rename "dev_node3" host "devbox3" port 
20000

alter multiplex server prod_node1 rename "dev_node1" host "devbox1" port 
20000


Even better, have these overridden by a configuration file or command 
line option.  Think: make it easier to put into docker (or similar) 
containers.


Administering IQ should be easy and SAP should avoid making DBAs and 
developers do unnecessary work.


jason


On 6/25/2018 5:04 PM, Jason Froebe wrote:
>
> In complex environments where there are thousands of users assigned to 
> a myriad of login policies, logical servers, etc the "official" slow 
> method can translate to far more than your estimated 5 minutes of 
> time.  Perhaps the 'best practices' should be updated to be practical 
> outside of engineering lab of SAP?
>
>
> jason
>
>
> On 6/25/2018 4:50 PM, Mumy, Mark wrote:
>>
>> In a perfect world, you are correct. Sometimes things fall through 
>> the cracks.  You method will save all of about 5 minutes of work and 
>> open the door for issues.  Our documented best practice won’t.  Not 
>> to mention all the scripts have to be modified or regenerated.  Can’t 
>> have the new environment syncing with production…. We have best 
>> practices for a reason.
>>
>> Mark
>>
>> *Mark Mumy*
>>
>> *Strategic Technology Incubation Group*
>>
>> *SAP Global Center of Excellence *| ***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#
>>
>> *From: *"iqug-bounces at iqug.org" <iqug-bounces at iqug.org> on behalf of 
>> Jason Froebe <jason.froebe at gmail.com>
>> *Date: *Monday, June 25, 2018 at 3:38 PM
>> *To: *"markdmumy at gmail.com" <markdmumy at gmail.com>
>> *Cc: *"iqug at iqug.org" <iqug at iqug.org>
>> *Subject: *Re: [IQUG] Cannot secondary server in an IQ Multiplex
>>
>> It's not a big deal if you connect via host/port that easily 
>> differentiates between environments.  Neither engine or database need 
>> to be specified in the connection string.
>>
>> Why would anyone use server broadcast in a corporate network 
>> anyways?  Simply disable it with "-sb 0" and be done with it.  No 
>> application in a corporate environment should ever rely on it.
>>
>> jason
>>
>> On 6/25/2018 4:21 PM, Mark Mumy wrote:
>>
>>     Except that the servers in two multiplex now have the same names.
>>      Not a direct issue, but if you don’t manage server broadcast
>>     then you could have apps in the wrong server.  Best to be safe
>>     and follow our documented steps for moving to a new server.
>>
>>     Mark
>>
>>
>>
>>         On Jun 25, 2018, at 3:00 PM, Jason Froebe
>>         <jason.froebe at gmail.com <mailto:jason.froebe at gmail.com>> wrote:
>>
>>         actually you don't have to drop the servers.  Simply start up
>>         the coordinator with "-iqmpx_ov", log into the coordinator
>>         issuing "alter multiplex server <secondary server> host 'new
>>         address' port <new port>" for each secondary server and
>>         lastly for the coordinator (which will shutdown the
>>         coordinator).  Start the coordinator without "-iqmpx_ov",
>>         issue sp_iqmpx to ensure the secondary servers are still
>>         included, resync the secondary servers and start per normal.
>>
>>         This method allows you to keep your various profiles and
>>         settings for multiplex.
>>
>>         jason
>>
>>         On 5/18/2018 9:53 AM, Mumy, Mark wrote:
>>
>>             When you move IQ to another set of servers, you have to
>>             start the old coordinator node in single user mode then
>>             drop all servers.  Once that’s done, you can then add the
>>             servers back in.
>>
>>             The temp device can make sense if you don’t have the same
>>             devices on the new servers.  There is an option called
>>             -iqnotemp that can be used to start IQ without temp. 
>>             Then you can add the new temp location(s) and drop the
>>             old file(s).
>>
>>             While you are using vMotion, what you are really doing at
>>             the IQ level is a backup and restore to a new set of
>>             servers.  You need to follow the proper recovery
>>             procedure in this case.
>>
>>             This link will walk you through the process.  You just
>>             need to substitute the vMotion move where it talks about
>>             a restore in step 3.
>>
>>             https://help.sap.com/viewer/a893f37e84f210158511c41edb6a6367/16.0.11.12/en-US/a4d5737584f210158859803145b70072.html
>>
>>             That same manual also has some sections on -iqnotemp,
>>             though in different sections, but it still applies.
>>
>>             Mark
>>
>>             *Mark Mumy*
>>
>>             *Strategic Technology Incubation Group*
>>
>>             *SAP Global Center of Excellence *| ***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#
>>
>>             *From:*"iqug-bounces at iqug.org"
>>             <mailto:iqug-bounces at iqug.org><iqug-bounces at iqug.org>
>>             <mailto:iqug-bounces at iqug.org>on behalf of Allen
>>             Zhang<zyx_zhang at yahoo.com> <mailto:zyx_zhang at yahoo.com>
>>             *Date:*Thursday, May 17, 2018 at 5:43 PM
>>             *To:*"iqug at iqug.org"
>>             <mailto:iqug at iqug.org><iqug at iqug.org> <mailto:iqug at iqug.org>
>>             *Subject:*[IQUG] Cannot secondary server in an IQ Multiplex
>>
>>             We have few different datastores on-prem,
>>
>>             1. both Coordinator node and the Secondary node were
>>             originally located on IBM/SVC storage
>>
>>             2. we shut both above severs down, vMotion servers and
>>             database (i.e. all datastorage devices attached to these
>>             servers, basically all the .vmdk files for the Virtual
>>             Servers (VMs)) to a new datastorage i.e. PureDatastorage
>>
>>             3. Once every .vmdk files were migrated or vMotion(ed) -
>>             we brought the server/database up
>>
>>             4. then it complained with the temp device (w:) drive
>>
>>             5. I then thought there might be environment issues, so I
>>             did full restore as per usual document I  follow for
>>             refresh db
>>
>>             6. Now it complained with recovery issues
>>
>>             Below is the the error message on the Coordinator node:
>>
>>             WARNING : Multiplex environment incorrect for this server
>>
>>             Please connect and run procedure sp_iqmpxvalidate for help
>>
>>             TCPIP link started successfully
>>
>>             When I ran sp_iqmpxvalidate, it complains there is no
>>             temporary space for Secondary node.
>>
>>             Secondary node won't start and the error message on
>>             the Secondary node is here:
>>
>>             Recovery required to complete the last failover process.
>>             Please restart the server with failover switch
>>
>>             Anyone knows how we can start up the Secondary node so
>>             that I can add raw device to IQ_SYSTEM_TEMP dbspace?
>>
>>             Thanks
>>
>>             Allen
>>
>>
>>
>>
>>             _______________________________________________
>>
>>             IQUG mailing list
>>
>>             IQUG at iqug.org <mailto:IQUG at iqug.org>
>>
>>             http://iqug.org/mailman/listinfo/iqug
>>
>>
>>         _______________________________________________
>>         IQUG mailing list
>>         IQUG at iqug.org <mailto:IQUG at iqug.org>
>>         http://iqug.org/mailman/listinfo/iqug
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://iqug.org/pipermail/iqug/attachments/20180625/fb5a8d37/attachment-0001.html>


More information about the IQUG mailing list