Symptom: Five rac sets of Oracle11gR2.0.3.0 have been installed since April this year. Two sets in February, two sets in February, one set in February, and one set in February, which are distributed in three different data centers, in essence, it is also three different customers. After each installation, You need to restart the machine to see if any configuration can be set up as required. However
Symptom: a total of five rac sets of Oracle11g R2.0.3.0 have been installed since April this year. Two sets in February, two sets in February, one set in February, and one set in February, which are distributed in three different data centers, in essence, it is also three different customers. After each installation, You need to restart the machine to see if any configuration can be set up as required. However
Symptom:
A total of five rac sets of Oracle11g R2.0.3.0 have been installed since April this year. Two sets in February, two sets in February, one set in February, and one set in February, which are distributed in three different data centers, in essence, it is also three different customers. After each installation, You need to restart the machine to see if any configuration can be set up as required. But every time we find that grid, oracle and other related services can be well established, vip resources can also be well established, ifconfig on the host can also see vip, scan ip can be bond to public ip, both machines can ping vip, scan ip, or even the same network segment, but other network segments cannot ping vip, scan ip, however, the public ip can be pinged. It's strange, but after several long periods of time, some are half an hour, some are two hours. In this way, when all applications connect to the database through vip and scan ip addresses (in fact, vip and scan ip addresses should be used to connect to the database), once the machine is restarted or the vip resource is restarted, before the scan ip address is pinged, all applications cannot access the database, which will have a major impact on the business.
Analysis:
Two sets were installed in the same data center in July. At that time, I always thought this should be a problem with the network configuration of the data center. I also found a network engineer to follow up, network engineers captured a large number of logs for analysis. I am also analyzing it from the Oracle perspective. At that time, I had been skeptical about the problem of the subnet mask of the vip, but I would like to think about it again, when installing 11g rac, there is no need to use vipca to set the subnet mask of the vip.
Two months later, I installed two sets of 11g r2.0.3.0 rac in March. One and the other two sets of rac installed in April are in the same data center, another data center is located in another remote data center. However, after the installation is complete, the same phenomenon occurs after the restart. At this time, I suspect that the network is set and the subnet mask of the vip is still suspected.
After another month, I installed a set of rac of the same version in another data center. This is also a problem. Is this a new version bug?
The same version of rac was installed in the two rac data centers in July.
I installed 11g r2.0.2.0 in these data centers last year.
At this point, I gradually suspected that the new version of the bug was found today, so I am very happy:
Bug 13440962 Different subnet failed to connect to vip after restart vip
This note gives a brief overview of bug 13440962.
The content was last updated on: 01-FEB-2012
Clickherefor details of each of the sections below.
Affects:
Product (Component) Oracle Server (PCW)
Range of versionsbelievedto be affected Versions >=11.2.0.3 but BELOW 12.1
Versionsconfirmedas being affected
11.2.0.3
Platforms affected Generic (all/most platforms affected)
It is believed to be aregressionindefabebehaviour thus:
Regression introduced in 11.2.0.3
Fixed:
This issue is fixed in
12.1 (Future Release)
Symptoms:
Related:
(None Specified)
Cluster Ready Services/Parallel Server Management
Description
This is a regression fix for problem introduced by patch 11069846.
The change in this patch (patch 13440962) fixes a problem with 4 extra
Bytes in the GARP message and removes an extra unicast GARP packet
The router.
Rediscovery Notes:
After upgrading to 11.2.0.3, after vip failover, the ip address is
Not pingable from a different subnet on Linux.
(This problem is seen only on Linux) WorkaroundAfter vip failover, run command
/Sbin/arping-U-c 3-I
To update the ARP table of router.
Please note: The above is a summary description only. actual symptoms can vary. matching to any symptoms here does not confirm that you are encountering this problem. for questions about this bug please consult Oracle Support.
References
Bugs: 13440962 (This link will only work for PUBLISHED bugs)
Note: 245840.1 Information on the sections in this article
