8127: Cannot create ACTIVE STANDBY PAIR scheme because another replication

Hi All,
I am trying to define ACTIVE STANDBY PAIR replication scheme on the Datastore which have already bidirectional replication is defined on few tables ,
Datastore1 ,Datastore2 are with Bidirectional replication defined on few tables , i want to have Active/stand by replication scheme between datastore1 and Datastore3, while trying to define ACTIVE STANDBY PAIR replication scheme on Datastore1 , i am facing below error
8127: Cannot create ACTIVE STANDBY PAIR scheme because another replication
Could you please is this how to achieve this Configuration

This configuration is not possible. You cannot mix classic replication (CREATE REPLICATION) with active/standby pair replication (CREATE ACTIVE STANDBY PAIR). They are mutually exclusive.

Similar Messages

  • 8130: CREATE ACTIVE STANDBY PAIR must only be run on one of the MASTER node

    plz give me some help~~thx
    帖子经 user11036969编辑过

    Here's the original post (the forum seems to have truncated it for some reason):
    Content of the new Post:
    Command> CREATE ACTIVE STANDBY PAIR abmmd ON "node1",abmmd ON "node2"
    > STORE abmmd ON "node1" PORT 21000 TIMEOUT 30
    > STORE abmmd ON "node2" PORT 20000 TIMEOUT 30;
    8130: CREATE ACTIVE STANDBY PAIR must only be run on one of the MASTER nodes.
    TypeMode =0
    plz give me some help~~thx
    This error means that when TimesTen is processing this statement and asks the operating sysstem for the official hostname of the local node the O/S is returning somethign different to 'node1' or 'node2'.
    it may be that you have incorrectly set the hostname to inculue a DNS domain (e.g. node1.xxx.yy.zzz).

  • Standby remains "IDLE" after creating Active-Standby pair

    hi gurus
    After creating an active stand by pair,the standby node can not step in "standby" role.
    On the standby:
    Command> call ttrepstateget;
    +< IDLE >+
    +1 row found.+
    On the active:
    Command> call ttrepstateget;
    +< ACTIVE >+
    +1 row found.+
    ttrepadmin -showstatus command on the active shows:
    [email protected]:/oracle/app/tt01/TimesTen/tt01/info$ttrepadmin -showstatus ocs01
    Replication Agent Status as of: 2010-04-21 09:24:48
    DSN                         : ocs01
    Process ID                  : 225840 (Started)
    Replication Agent Policy    : manual
    Host                        : NJZAPP1
    RepListener Port            : 17015
    Last write LSN              : 0.9662520
    Last LSN forced to disk     : 0.9662520
    Replication hold LSN        : 0.9583928
    Replication Peers:
    Name                     : OCS01
    Host                     : PJZAPP1
    Port                     : 18011  (Connected)
    Replication State        : STARTED
    Communication Protocol   : 24
    TRANSMITTER thread(s):
    For                     : OCS01
    Start/Restart count   : 97
    Send LSN              : 0.9583928
    Transactions sent     : 0
    Total packets sent    : 97
    Tick packets sent     : 0
    MIN sent packet size  : 139
    MAX sent packet size  : 139
    AVG sent packet size  : 139
    Last packet sent at   : 09:24:31
    Total Packets received: 0
    Most recent errors (max 5):
    TT16060 in transmitter.c (line 6605) at 08:44:16 on 04-21-2010
    TT16060 in transmitter.c (line 6605) at 08:54:19 on 04-21-2010
    TT16060 in transmitter.c (line 6605) at 09:04:22 on 04-21-2010
    TT16060 in transmitter.c (line 6605) at 09:14:25 on 04-21-2010
    TT16060 in transmitter.c (line 6605) at 09:24:28 on 04-21-2010
    RECEIVER thread(s):
    For                     : OCS01
    Start/Restart count   : 1
    Transactions received : 0
    Total packets sent    : 1
    Tick packets sent     : 0
    MIN sent packet size  : 80
    MAX sent packet size  : 80
    AVG sent packet size  : 80
    Last packet sent at   : 09:24:45
    Total Packets received: 1
    MIN rcvd packet size  : 139
    MAX rcvd packet size  : 139
    AVG rcvd packet size  : 139
    Last packet rcvd'd at : 09:24:45
    Most recent errors (max 5):
    TT16060 in receiver.c (line 2044) at 09:24:45 on 04-21-2010
    ttrepadmin -showstatus command on the standby shows:
    ttrepadmin -showstatus ocs01
    Replication Agent Status as of: 2010-04-21 09:38:25
    DSN                         : ocs01
    Process ID                  : 184590 (Started)
    Replication Agent Policy    : manual
    WARNING: Replication Agent has not finished initialization yet.
    And ttdaemonlog -r shows lots of this message:
    +2010-04-21 09:25:49.43 Warn: REP: 225840: OCS01:receiver.c(2044): TT16060: Failed to read data from the network. select() timed out+
    How to handle this problem?
    Thank you very much.
    Edited by: KevinMao on Apr 20, 2010 6:39 PM

    Hi Kevin
    the obvious culprits: did you create the standby with the 'duplicate' command? Did you start the replication agents for both active and standby?
    Can you share the 'create active standby ...' command you used and the steps you followed to set this up?

  • Can I replicate new tables using the ACTIVE STANDBY PAIR replication scheme

    I have created myself a simple setup using an active/standby pair with a single subscriber like so:
    CREATE ACTIVE STANDBY PAIR cie ON "tt-test1", cie ON "tt-test2" RETURN RECEIPT SUBSCRIBER cie on "tt-test3";
    I have then added some tables on the master, they did not replicate automatically. I find this:
    Command> repschemes;
    Replication Scheme Active Standby:
    Master Store: CIE on TT-TEST1
    Master Store: CIE on TT-TEST2
    Master Return Service: Return Receipt
    Subscriber Store: CIE on TT-TEST3
    Excluded Tables:
    Included Tables:
    List too long (59 items), use verbosity 4 to display
    My question is ... how do I include these tables in replication?
    Do I need to trash and clone the secondary master store and the subscriber again? Even doing that won't add the tables to the replication scheme so I don't think that is a solution.
    I couldn't find much documentation on the ALTER REPLICATION statement but from what I could find it requires me to know the 'name' of the replication scheme and the examples in the documentation didn't work when I used 'Active Standby' as the scheme name in the statement.
    Am I being retarded here? Is this a limitation of using the ACTIVE STANDBY PAIR replication model?
    Thanks in advance.

    When you setup and rollout the ACTIVE/STANDBY pair (or indeed legacy replication) it only includes tables that already exist. The normal deployment process is:
    1. Create the first datastore (the one which will initially be the 'active').
    2. Create (and populate) all necessary tables.
    3. Create the active/standby pair replication scheme.
    4. Start the repagent
    5. Make the datastore active by calling ttRepStateSet('ACTIVE')
    6. Use ttRepAdmin -duplicate to create the standby store from the active
    7. Start repagent at standby
    8. Use ttRepAdmin -duplicate to create the subscriber store from the standby
    7. Start repagent at subscriber
    If you need to add/remove tables later you must do the following:
    At active node:
    1. Create any new tables (and populate them) as needed
    2. Stop repagent
    3. Execute ALTER ACTIVE STANDBY PAIR with INCLUDE and/or EXCLUDE clauses as required
    4. Start repagent
    Then you need to redeploy the other stores:
    At standby:
    5. Stop repagent
    6. Drop datastore (ttDestroy)
    7. Re-create datastore from active using ttRepAdmin -duplicate
    8. Start repagent
    At subscriber:
    9. Stop repagent
    10. Drop datastore (ttDestroy)
    11. Re-create datastore from standby using ttRepAdmin -duplicate
    12. Start repagent
    This is documented in the TimesTen Replication Guide in the section on administering an active/standby pair.

  • Active Standby Pair Clustering.

    Hi Chris, I had created ActiveStandby Pair as follows:
    Server 1 => DSN: TTCluster1
    Server 2 => DSN: TTCluster2.
    Then I created ActiveStandby Pair in Server1, Started RepAgent and then Duplicated the DSN on Server 2 with name TTCluster 2. It worked fine.
    Now to access it from the client server mode, I created Client DSN on Client machine using Virtual IP. (Using Linux Cluster Manager).
    But inthis case I had to create two client DSN. TTCluster1Client and TTCluster2client. Since Application can connect to only one DSN and shifting to other while failover is very difficult.
    So I am trying following model now, Let me know your views on this.
    Server 1 and Server 2, both will have same DSN name "TTCluster".
    Client Machin will have only one DSN "TTClusterClient" using VIP.
    When the Server1 failes, Server 2 will take over and there is no need of shifting client DSN. Application will be routed to Server 2 after switch over.
    Step1: created server DSN "TTCluster" on Server 1 and Server 2.
    Step2: created user 'ttcluster' on Server 1 and Server 2.
    Step3: Create DataStore TTCluster on Server 1. (By connecting to TTCluster).
    Step4: Create Cache Groups (AWT) on Server1.
    Step5: Started Cache Agent on Server1.
    Step6: Created ActiveStandby Pair on Server1 as follows:
    TTCluster ON "wabtectimesten.patni.com",
    TTCluster ON "wabtectimesten2.patni.com"
    STORE TTCluster PORT 20000 TIMEOUT 120;
    Step8: executed ttrepstateset('ACTIVE') on server1.
    Step9: Started Replication Agent on Server1.
    Step10: Duplicated DataStore on Server2.
    Server2 is not coming up as Standby. The log on Server1 shows following messages:
    15:19:33.83 Warn: REP: 8671: TTCLUSTER:receiver.c(1723): TT16060: Failed to read data from the network. select() timed out
    15:19:37.09 Err : REP: 8671: TTCLUSTER:receiver.c(3428): TT16142: Failed to retrieve peer information. No peers found
    15:19:37.09 Err : REP: 8671: TTCLUSTER:transmitter.c(5523): TT16229: Transmitter thread failure due to lack of state consistency at subscriber store _ORACLE
    While creating replication scheme I have mentioned.
    STORE TTCluster PORT 20000 TIMEOUT 120;
    I need to define the timeout for both DataStores. How will I do that?
    The above timeout will be applicable for which datastore??
    Can you please let me know if I am going in the right direction???

    Hi Tanweer,
    When designing a monitoring scheme for TimesTen one has to bear a few things in mind (though not all will be relevant in every case):
    1. There could be multiple 'instances' of TimesTen installed on a machine. Each instance is completely independent and must be monitoried separately.
    2. Each instance has a 'main daemon' (timestend) that is the instance master supervisor. If this daemon is running and healthy then the 'instance' is considered to be 'up' and 'healthy'.
    3. Each instance can manage multiple datastores. Each datastore is independent from the others and so each datastore must be monitored separately.
    4. Each datastore may be using replication and/or cache connect. If so, these must also be monitored as well as the datastore since it is perfectly possible e.g. for the datastore to be healthy but for replication to be 'down'.
    Depending on your requirements, your monitoring mechanism must 'model' this structure and relationships...
    - If the instance main daemon is not running, or is not responding, then the entire instance is 'down' and all datastores managed by the instance should also be considered as 'down'
    - If a datastore goes down (e.g. call invalidate), other stores in the instance are not affected and neither is the main daemon for the instance. They will continue to operate normally.
    - A datastore may be healthy in itself but maybe replication or cache connect for the datastore is not healthy. Do you then consider the datastore as down? That depends on your applications requirements!
    Hopefully this helps to clarify the interrelationship of components. Crashing a datastore by calling 'invalidate' does not crash the daemon (if it does then that is a bug!).
    For monitoring the instance (main daemon) there are a few options:
    1. ps -ef | grep timestend. This can detect if the daemon process is running but not if it is healthy...
    2. Connect to a datastore. Every connect/disconnect request is processed via the main daemon so if the daemon is not healthy this will result in some error (usually a 'cannot communicate with the daemon' error). However, connect/disconnect are relatively expensive so you don't want to do this too often.
    3. Have a monitoring process that maintains an open connection to the instance level datastore (DSN=TT_<instancename>). Periodically (as often as required within reason) it can execute the built in procedure ttDataStoreStatus() passing it the pathname of the instaance datastore checkpoint files (obtainable from the built in procedure ttConfiguration). This procedure communicates with the main daemon so will either return success (meaning daemon is okay) or an error (daemon is in big trouble).
    If you have to do the test from a script then I would suggest that (2) is best but if you can do it from a continually running monitoring process then (3) is better.
    For monitoring a datastore the best way to ascertain overall health is as follows:
    1. Have a dummy table in the datastore. And as part of the check update a row in th dummy and commit the transaction. If this returns success then this shows that the datastore is up and able to service update requests (which means it is also okay for read requests).
    2. You should also monitor the available space in the datastore and warn someone or something if the free space gets too low. You can query space allocation, current usage and high watermark usage from the SYS.MONITOR table. You can also configure TimesTen to generate SNMP traps and/or return warnings to applications if space usage exceeds some configured threshold. The objective is to take proactive action to prevent the datastore becoming full since that will require more disruptive corrective action.
    For monitoring replication you should periodically:
    1. Check that the datastore's repagent is running (you can do this using ttDatastoreStatus)
    2. Check the status of each replication peer by calling ttReplicationStatus and checking the values of pstate (should be 'start') logs (if this value increases over time then the peer is in some kind of trouble) and lastMsg (if there is no message from the peer for a long time then it may be in some kind of trouble).
    3. Sometimes an easier way is to have a dummy table set up for synchronous replication and do an update+commit for a row in that table. if replicatioin is working the commit will return within a few ms at most. If you get a timeout error returned that tells you that replication is in trouble,
    To monitor cache connect is not so easy at present.
    For AWT cache groups, the same monitoring as is used for replication is okay).
    For SWT cache groups, if the sync to Oracle is not working every commit will get an error (so that's kind of obvious).
    For AUTOREFRESH cache groups it's a bit harder. There is currenyly no supported way to determine when the last successful autorefresh occurred. I am hoping this capability will be added in a future release.
    Sorry if that is a bit long winded - I hope it helps...

  • Problem with Active Standby Pair

    Hi ALL!
    I have a problem with Active Standby Pair replication.
    I have 2 instance TT on host1 and host2
    On host1 i created 2 data store rep1 and rep2
    On host2 i created 1 data store t1
    ALL data stores identical, and have one table REP_TAB.
    AFter this i work with rep1 ds:
    Creating active standby pair:
    create active standby pair rep1 on "host1",
                                          t1 on "host2"
    subscriber rep2 on "host1"
    store rep1  on "host1"  port 18000 timeout 30
    store t1 on "host2"     port 18000 timeout 30and starting repagent
    call ttrepstart;After this i try using ttrepadmin utility and ALWAYS GET this error
    C:\Documents and Settings\user1>ttrepadmin -duplicate -from rep1 -host "host1" rep4
    Enter password for 'tt':
    TT12048: Error performing backup at source.  More information can be found in th
    e source's message log
    TT7001: REP1:receiver.c(4979): TT7001: User authentication failedPasswort right. I dont know what i am doing wrong? Please Help!

    Did you enable Access Control in this instance when you installed? If so, have you created the relevant users in the TimesTen instance?
    If you have access to Metalink you may find Note 421220.1 useful in clarifying this process, and also for avoiding other problems you may encounter after performing a successful duplicate.

  • Active standby pair Replication scheme

    I just want to know that is this possible to have "Active Active pair".
    Actually i want to create pair in which both Masters are in Active mode.None master is in standby mode.
    Please ....

    Could you please elaborate why you need active/active? Active/active configurations are potentially dangerous with any replication technology and are discouraged. TimesTen Active/Standby pair replication does nto support active/active (the clue is in he name :-)). TimesTen legacy replication does support active/active in some scenarios but if you use that then you cannot use Oracle caching. If you want to use both replication and Oracle caching then realistically you must use Active/Standby pair replication.

  • Safe way to reboot Active/Standby Pair

    I have the need to reboot my ASA5520. We have a Active/Standby pair and I want to make sure that they come up playing nicely and not in a tug of war.
    Any advice on the proper way to reload these machines and optimize uptime??

    If you are not bothered as to which one becomes primary then simply pick one, reload, wait until it has come up and then reload the other one.
    As long as you have failover correctly configured there should be minimal downtime, just the time it takes to fail over when you reload.
    If you want the primary to stay as the primary then you need to reload this one first, let it come up as standby, then reload the other one and the former primary will now become the primary again.
    Note that reloading the standby first is the best approach simply because you only then have one failover ie. when the standby comes backup and resumes it's standby funtionality and then you reload the primary there will be a failover.

  • Active/standby pair + Oracle db parameter FAILTHRESHOLD

    Assume we have 3 databases
    TT_A - timesten Active
    TT_S - timesten Standby
    O - oracle db.
    SETURN MODE twosafe
    Storage atributes
    FAILTHRESHOLD set to 10 value.
    Two timesten databases are in consistent state.
    Aplication update TT_A.
    TT_S replication data to ORACLE.
    Assume we stop replication.
    So application can run on TT_A.
    After 10 log switch TT_S will be marked as failed.
    All logs waiting for TT_S will be delete.
    So how oracle receiv the data ?

    In active standby pair replication, cache operations are tightly coupled with replication. In normal operation of AWT cache group within an A/S pair, updates occur at the active which replicates them to the standby and then the standby pushes them to Oracle. The active and standby continually exchange housekeeping information about what transactions have been committed at the standby and which have been committed, via AWT, at Oracle. The active and the standby will only purge transaction logs for transactions that they know are safely stored in all 3 places. If the standby fails then, as long as you tell the active that it has failed (via a call to ttRepStateSave()), the active will take over the AWT push from the last transaction that it knows was safely committed in Oracle. No data will be lost.
    If you are using oracle Clusterware to manage your A/S pair then you don't need to do anything as Clusterware will perform the necessary notification to the active that the standby has failed.

  • Ask timesten 11.2 Using Oracle Clusterware to Manage Active Standby Pair

    Using Oracle Clusterware to Manage Active Standby Pairs
    What is that mean ?
    I have to use Share Storage for... Oracle Clusterware?
    I think right?... or wrong ?
    Can I have VIP on Master node, and then master down... standby will active with VIP, right ?

    A TimesTen A/S pair is a replicated configuation where a pair of TimesTen datastores, usually located on different machines, act in many ways as a single unit. The active master can process both queries and DML (insert/update/delete) while the standby master can only process queries (think of this as a little like Active Dataguard). Applications that run on the same machine as one of the TT datastores can connect to it via the very high performance 'direct mode' while applications running on other machines can access the datastores in client/server mode. There is a clearly defined procedure for failing over if the active master fails (which involves promoting the standby master to active) and for recovering a failed store back to the correct role. Direct mode applications must failover with the datastore whereas for client/server applications the connection(s) need to be failed over. The basic A/S pair replication mechanism has been available since TimesTen 6.0. The replication configuration is defined via special SQL syntax and monitoring and management (failover control etc.) is performed by way of built-in procedure calls. However, in TT 6.0 and 7.0 the actual monitoring and management of the A/S pair, including failover, is left for the user to implement themselvses or via some custom integration with an external cluster manager.
    TimesTen 11g adds two major new capabilities:
    1. Automatic client connection failover for client/server connections. Think of this as very similar to Oracle DB TAF and FAN. This does not require VIPs or Clusterware since it is implemented completely within TimesTen. However it works very well when used in onjunction with Clusterware.
    2. A deep integration between TimesTen and Oracle Clusterware. All aspects of Timesten A/S pair definition, deployment, management and recovery are handled by Clusterware. There is just a single configuration file and a single TimesTen utility (ttCWAdmin) involved. Of course you need a properly configured Clusterware setup first which will require some form of shared storage (for OCR and voting disks) but TT storage (checkpoint and log files) does not need to be on shared storage. Setting up TT for use with Clusterware is very quick and easy (maybe 30 minutes the first time you do it and much quicker thereafter once you know what you are doing). From then on Clusterware will manage all aspects of failover and recovery completely automatically. VIPs are not required but can be used if desired e.g. for application failover purposes. Clusterware can also manage the failover of direct mode applications. Also, you can define automated backup cycles and spare nodes that can be used if a node suffers some permanent failure. The Clusterware integration offers very rich functionality but also very fast failover (typically just a few seconds in my testing).
    Hope that helps clarify.

  • Contacts cannot be synced at this time because another computer is currentl

    Just got to say, mobile me is incredibly fragile. Apple should rename the service mobile beta.
    I have two problems,
    1) "Contacts cannot be synced at this time because another computer is currently syncing this data". I have two PCs and made some changes to the adress book. Now I get this error every fifteen minutes on my work PC. This is incredibly annoying. I am guessing that there is a dialog box displayed on my home PC warning that more than 5% of my data has changed and do I want to continue.
    Apple, please take this dialog box out of the Sync transaction operation otherwise it looks the entire process for all clients, if a user cannot access their PC at that moment to respond to the dialog.
    2) I created a new Address book Group on the server/cloud and populated it with several addresses. On my iPhone the group is shown but it is empty. Is this possibly related to the problem (1)?.
    Anybody have any suggestions? Is my idea about the cause correct?

    You could try again later but usually, that message means that the server detected a jailbroken device. Has your iPad been hacked or jailbroken? Or, has your computer been used with a hacked or jailbroken device?

  • Can the standby become the active for the active standby pair

    Hi all,
    Will the standby database take over the duty of the active database when the active database fails?
    If not is there only a read-only standby database and how high availability of the active stand pair works?

    That will work for a simple test/demo environment but it is not robust enough to use for real. If implementing a robust HA monitor and management framework were that easy then we wouldn't need Clusterware...What about all the different failure conditions, combinations and corner cases? Please don't make the mistake of thinking that this is close to adequate for production usage. You will just create a heap of pain for yourself. State management and co-ordination across multiple nodes is a difficult and complex problem which is why cluster managers have evolved into the thinsg they are today.
    Just one simple example; the network that connects your detection program to both nodes is working fine but the network between the TT nodes is not. How does your monitor (a) detect this and (b) handle it? What of the network between the monitor and one of the nodes fails but the connection to the other node and between the TT nodes is okay? How is that detected/handled? Ensuring that you 'do the right thing' in each case and don't take any action that could result in loss of service? And these are the 'easy' cases...

  • IPS modules in Cisco ASA 5510 Active/Standby pair.

    All, I am looking to add the IPS module to my ASA 5510's. I am contemplating only purchasing one module and placing it in the active ASA. I am willing to accept that in a failure scenario I will loose the IPS functionality until the primary ASA is recovered. I have not had a chance to talk to my SE to see if this is even possible. Has anyone attempted a deployment such as this? Will it work and is it supported?
    Sent from Cisco Technical Support iPad App

    Ok, that is what I needed to know.  The purpose of us having an active/standby ASA is to keep the business up and going for the very rare times there could be an active ASA failure.  The purpose for the IPS would be to help protect and inspect traffic and is not necessary to keep the business running.  If we implement IPS I am not worried at all if during the times when the primary ASA is down (hasn't been down for over three years now) we lose the IPS funcationality.  This is not worth the $1000 extra per year to us.
    Thanks for the responses though.  That answers my questions.

  • Reboot ASA 8.4 (asdm 6.4) Active/Standby pair

    I manage a pair of ASAs (8.4 asdm 6.4) and am having trouble with traffic going thru a tunnel.  It was recommended to me that perhaps a reboot is in order.  I found the instructions at http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/admin_swconfig.html#wp1355970 (which I followed without actually upgrading the IOS, as all I wanted was both devices to reboot - one at at time without causing connection resets) but when I attempted it, the device that rebooted was always the same IP.  My question is at step  3 "when standby unit has finished reloading and is in the Standby Ready state, force the active unit to fail over to the standby unit by entering the following command on the active unit.
    active# no failover active
    But there is a note "Use show failover command to verify that the standby unit is in the standby ready state"  which I did. 
    This is the result of show failover from the 0.5 (primary) unit BEFORE issuing no failover active:
    Last Failover at: 05:32:10 EST Feb 9 2012
            This host: Primary - Active
                    Active time: 3732124 (sec)
                    slot 0: ASA5510 hw/sw rev (2.0/8.4(3)) status (Up Sys)
                      Interface management ( No Link (Not-Monitored)
                      Interface outside ( Normal (Monitored)
                      Interface inside ( Normal (Monitored)
                      Interface DBDMZ ( Normal (Monitored)
                      Interface WEBDMZ ( Normal (Monitored)
                    slot 1: ASA-SSM-4GE hw/sw rev (1.0/1.0(0)10) status (Up)
            Other host: Secondary - Standby Ready
                    Active time: 0 (sec)
                    slot 0: ASA5510 hw/sw rev (2.0/8.4(3)) status (Up Sys)
                      Interface management ( Normal (Not-Monitored)
                      Interface outside ( Normal (Monitored)
                      Interface inside ( Normal (Monitored)
                      Interface DBDMZ ( Normal (Monitored)
                      Interface WEBDMZ ( Normal (Monitored)
                    slot 1: ASA-SSM-4GE hw/sw rev (1.0/1.0(0)10) status (Up)
    So far so good.  Then I entered (on the PRIMARY-ACTIVE unit) the command no failover active and I got the following:
    NMEC-ASA5510-COLOVA# sho failover
    Failover On
    Failover unit Secondary
    Failover LAN Interface: failover Ethernet0/0 (up)
    Unit Poll frequency 500 milliseconds, holdtime 3 seconds
    Interface Poll frequency 5 seconds, holdtime 25 seconds
    Interface Policy 1
    Monitored Interfaces 4 of 110 maximum
    Version: Ours 8.4(3), Mate 8.4(3)
    Last Failover at: 11:02:26 EDT Mar 23 2012
            This host: Secondary - Active
                    Active time: 140 (sec)
                    slot 0: ASA5510 hw/sw rev (2.0/8.4(3)) status (Up Sys)
                      Interface management ( No Link (Not-Monitored)
                      Interface outside ( Normal (Monitored)
                      Interface inside ( Normal (Monitored)
                      Interface DBDMZ ( Normal (Monitored)
                      Interface WEBDMZ ( Normal (Monitored)
                    slot 1: ASA-SSM-4GE hw/sw rev (1.0/1.0(0)10) status (Up)
            Other host: Primary - Standby Ready
                    Active time: 3732178 (sec)
                    slot 0: ASA5510 hw/sw rev (2.0/8.4(3)) status (Up Sys)
                      Interface management ( Normal (Not-Monitored)
                      Interface outside ( Normal (Monitored)
                      Interface inside ( Normal (Monitored)
                      Interface DBDMZ ( Normal (Monitored)
                      Interface WEBDMZ ( Normal (Monitored)
                    slot 1: ASA-SSM-4GE hw/sw rev (1.0/1.0(0)10) status (Up)
      Thinking all was well, I now issued (from the same unit) the reload command.  Unfortunately my continuous pings to .0.5 and .0.6 show that 0.6 rebooted AGAIN!?! 
    Can someone tell me what I am doing wrong? 

    I guessed that might be the case, but am still unsure.  The IP I was pinging was the inside LAN interface (Eth
    LAN failover is configured using Eth0/0 (IPs and .254)  and State Failover with Eth0/1 (IPs and .254) "Inside" is Gig1/1 with IP (and .6 on the second unit) I would have expected either the LAN failover or the State failover IPs to change but not the LAN interface.  But perhaps I've got it backwards.  Thanks for your response. Patrick.


    We have this issue of ACTIVEX OBJECT ERROR when we execute the EXCEL CLIENT and click on RUN PACKAGE.
    Can anyone explain or experienced this error before ?

    Hi There
    Have you tried to recycle the EVServerDataMgr COM+ component and performed a IISRESET?
    if the error still persists, then you will need to investigate the issue further, and possibly follow Sanjeev's recommendations
    Kind Regards

Maybe you are looking for