Azure: Find the number of Fault Domains for region

A fault domain is a logical grouping of hardware within a data center that shares a common power source and network switch.

In cloud environments like Microsoft Azure or Oracle Cloud, fault domains help improve high availability by ensuring that resources (like virtual machines) are distributed across isolated hardware. This way, if a failure occurs in one fault domain (e.g., a power outage or hardware failure), it doesn’t affect the other domains.

In clustered environments such as Oracle RAC and others, it is highly recommended to distribute database nodes across different Availability Zones (preferably within close proximity). However, if the selected region does not support Availability Zones, or if the network latency between AZs is too high, you can instead distribute the nodes across different fault domains to ensure fault tolerance at the power and network switch level.

To verify how many fault domains are supported in your chosen region, run the following script from Azure CLI:

az vm list-skus --resource-type availabilitySets --query '[?name==`Aligned`].{Location:locationInfo[0].location, MaximumFaultDomainCount:capabilities[0].value}' -o Table

The output by June 11, 2025, is as follows (subject to change in the future):

Location            MaximumFaultDomainCount
------------------ -------------------------
AustraliaCentral 2
AustraliaCentral2 2
australiaeast 2
australiasoutheast 2
AustriaEast 2
BelgiumCentral 2
brazilsouth 3
BrazilSoutheast 2
CanadaCentral 3
CanadaEast 2
CentralIndia 3
centralus 3
CentralUSEUAP 1
ChileCentral 2
DenmarkEast 2
eastasia 2
eastus 3
eastus2 3
EastUS2EUAP 2
EastUSSTG 1
FranceCentral 3
FranceSouth 2
GermanyNorth 2
GermanyWestCentral 2
IndonesiaCentral 2
IsraelCentral 2
IsraelNorthwest 2
ItalyNorth 2
japaneast 3
japanwest 2
JioIndiaCentral 2
JioIndiaWest 2
KoreaCentral 2
KoreaSouth 2
MalaysiaSouth 2
MalaysiaWest 2
MexicoCentral 2
NewZealandNorth 2
northcentralus 3
northeurope 3
NorwayEast 2
NorwayWest 2
PolandCentral 2
QatarCentral 2
SouthAfricaNorth 2
SouthAfricaWest 2
southcentralus 3
SouthCentralUS2 2
SouthCentralUSSTG 2
southeastasia 2
SoutheastUS 2
SoutheastUS3 2
SoutheastUS5 2
SouthIndia 2
SouthwestUS 2
SpainCentral 2
SwedenCentral 3
SwedenSouth 2
SwitzerlandNorth 2
SwitzerlandWest 2
TaiwanNorth 2
TaiwanNorthwest 2
UAECentral 2
UAENorth 2
uksouth 2
ukwest 2
westcentralus 2
westeurope 3
WestIndia 2
westus 3
westus2 3
WestUS3 3

CRS-2549: Resource ‘ora.asmgroup’ cannot be placed on ‘rac1’ as it is not a valid candidate as per the placement policy

Problem:

After failed JDK patching on the 1st node, we tried troubleshooting and saw that ASM was not able to start:

# su - grid
$ sqlplus / as sysasm
SQL> startup nomount;
ORA-32004: obsolete or deprecated parameter(s) specified for ASM instance
ORA-39511: Start of CRS resource for instance '223' failed with error:[CRS-2549: Resource 'ora.asmgroup' cannot be placed on 'rac1' as it is not a valid candidate as per the placement policy
CRS-0223: Resource 'ora.asm' has placement error.
clsr_start_resource:260 status:223
clsrapi_start_asm:start_asmdbs status:223

Reason:

Prepatch modified RESOURCE_USE_ENABLED=0 for rac1 node:

[grid@rac1 ~]$ crsctl stat server -f

NAME=rac1
MEMORY_SIZE=63465
CPU_COUNT=8
CPU_CLOCK_RATE=2499
CPU_HYPERTHREADING=1
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=0
SERVER_LABEL=
PHYSICAL_HOSTNAME=
CSS_CRITICAL=no
CSS_CRITICAL_TOTAL=0
RESOURCE_TOTAL=0
SITE_NAME=stsfilive
STATE=ONLINE
ACTIVE_POOLS=Free
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub

NAME=rac2
MEMORY_SIZE=63465
CPU_COUNT=8
CPU_CLOCK_RATE=2499
CPU_HYPERTHREADING=1
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
….

Solution:

Connect to the failing node and run:

[root@rac1 ~]# crsctl set resource use 1

Start ASM.

SESSIONS WAITING ON INACTIVE TRANSACTION BRANCH, GLOBAL HASH COLLISION 12c, 11g Oracle RAC(distributed transaction)

When performing XA transactions against a multi-node Oracle RAC configuration, some branches of the transaction may not commit.. this is a known bug, but to tell the truth no bug fix helped me to solve this problem until I came across IBM technote. https://www-304.ibm.com/support/docview.wss?uid=swg21460967

There are several workarounds but I prefer Work around 1.  I have used it and works perfectly.

1. If using pfile (init.ora) files, add the following line to the file:

_clusterwide_global_transactions=false

2. If using an spfile, issue the following command from SQL*Plus:

alter system set “_clusterwide_global_transactions”=false scope=spfile

3. Restart the database (you can restart nodes , one by one)

Problem should dissapear.