ORA-13226 interface not supported without a spatial index

La requête suivante m'a donné le message d'erreur ci-après:

SELECT DOC1.SER_NO_SEQ, DOC1.DOC_NO_SEQ FROM CIG_DOCUMENT DOC1, CIG_ZONE_RECHE ZRE1
WHERE SDO_RELATE ( DOC1.SHAPE_M, ZRE1.SHAPE, 'MASK=ANYINTERACT QUERYTYPE=WINDOW' ) = 'TRUE'
AND ZRE1.SES_CODE_SESSI='Z+i8zRHOva7Q7AhlJw0j61cS6Jg='
AND DOC1.SER_NO_SEQ IN (1099,1918,1905,2194);

ORA-13226: interface non prise en charge sans index spatial
ORA-06512: à "MDSYS.MD", ligne 1723
ORA-06512: à "MDSYS.MDERR", ligne 8
ORA-06512: à "MDSYS.SDO_3GL", ligne 88

Le message d'erreur fait allusion à un problème d'index spatial. Vérifions donc le statut des indexes spatial:

select OWNER, INDEX_NAME, STATUS, DOMIDX_STATUS, DOMIDX_OPSTATUS, FUNCIDX_STATUS, ITYP_NAME
from   dba_indexes
where  INDEX_TYPE = 'DOMAIN'
and ITYP_NAME = 'SPATIAL_INDEX'
and (DOMIDX_STATUS<>'VALID' or DOMIDX_OPSTATUS<>'VALID' or FUNCIDX_STATUS<>'VALID');

OWNER   INDEX_NAME   STATUS   DOMIDX_STATU DOMIDX FUNCIDX_ ITYP_NAME
------- ------------ -------- ------------ ------ -------- ---------------
CIG     DOC_AS_IS    VALID    VALID        FAILED          SPATIAL_INDEX
CIG     DOC_P_IS     VALID    VALID        FAILED          SPATIAL_INDEX

En essayant de recréer les indexes en question, j'obtiens:

SQL> DROP INDEX CIG.DOC_AS_IS FORCE;
Index supprimé.
SQL> CREATE INDEX DOC_AS_IS ON CIG_DOCUMENT
  2  (SHAPE_M)
  3  INDEXTYPE IS MDSYS.SPATIAL_INDEX
  4  PARAMETERS('sdo_indx_dims=2 sdo_dml_batch_size=1')
  5  NOPARALLEL;
CREATE INDEX DOC_AS_IS ON CIG_DOCUMENT
*
ERREUR Ó la ligne 1 :
ORA-29855: erreur d'exÚcution de la routine ODCIINDEXCREATE
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Error in spatial index: [mdrcrtxfergm]
ORA-13249: Error in spatial index: [mdpridxtxfergm]
ORA-13200: erreur interne [ROWID:AAAipHAAXAAAAk7AAG] dans l'indexation spatiale.
ORA-13206: erreur interne [] lors de la crÚation de l'index spatial
ORA-13033: DonnÚes non valides dans le champ SDO_ELEM_INFO_ARRAY de l'objet SDO_GEOMETRY
ORA-06512: Ó "MDSYS.SDO_INDEX_METHOD_10I", ligne 10
SQL> DROP INDEX CIG.DOC_P_IS FORCE;
Index supprimé.
SQL> CREATE INDEX DOC_P_IS ON CIG_DOCUMENT
  2  (SHAPE_P)
  3  INDEXTYPE IS MDSYS.SPATIAL_INDEX
  4  PARAMETERS('layer_gtype=MULTIPOINT sdo_indx_dims=2 sdo_dml_batch_size=1')
  5  NOPARALLEL;
CREATE INDEX DOC_P_IS ON CIG_DOCUMENT
*
ERREUR Ó la ligne 1 :
ORA-29855: erreur d'exÚcution de la routine ODCIINDEXCREATE
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Error in spatial index: [mdrcrtxfergm]AAAipHAAXAAAAk7AAG
ORA-13249: Error in spatial index: [mdpridxtxfergm]
ORA-13200: erreur interne [ROWID:AAAipHAAXAAAAk7AAG] dans l'indexation spatiale.
ORA-13206: erreur interne [] lors de la crÚation de l'index spatial
ORA-13033: DonnÚes non valides dans le champ SDO_ELEM_INFO_ARRAY de l'objet SDO_GEOMETRY
ORA-06512: Ó "MDSYS.SDO_INDEX_METHOD_10I", ligne 10
SQL>

Conclusion:

Il y a un problème au niveau de l'enregistrement dont le ROWID=AAAipHAAXAAAAk7AAG.

Après avoir corrigé cet enregistrement, j'ai recréé les indexes et la requête a fonctionné.

Référence:

Spatial Healthcheck Shows Index Status Failed [ID 1430629.1] 

Si cette erreur est dûe à l'utilisation de lien base de données (database link), il faut savoir que cela n'est pas supporté.
Voir le document Spatial Query Over a Database Link Fails With ORA-13226 or ORA-22804 [ID 374321.1] 

Hope it helps. 

MEMORY_TARGET, MEMORY_MAX_TARGET

Pour calculer les valeurs des paramètres MEMORY_TARGET, MEMORY_MAX_TARGET à partir des valeurs actuelles de SGA_TARGET, PGA_AGGREGATE_TARGET, SGA_MAX_TARGET, utiliser le script suivant:

Select '-- Memory Target = '||round(to_char((qry_sga_target.value+

        greatest(qry_pga_target.value,qry_pga_alloc.value)))/1024/1024)||' MB'||chr(10)||

       'Alter system set memory_target='||

       to_char((qry_sga_target.value+greatest(qry_pga_target.value,qry_pga_alloc.value)))||' scope=spfile sid=''*'';'||chr(10)||

       '-- Memory Max Target = '||round(to_char((qry_sga_max.value+

        greatest(qry_pga_target.value,qry_pga_alloc.value)))/1024/1024)||' MB'||chr(10)||

       'Alter system set memory_max_target='||

       to_char((qry_sga_max.value+greatest(qry_pga_target.value,qry_pga_alloc.value)))||' scope=spfile sid=''*'';'||chr(10)||

       'Alter system reset sga_target scope=spfile sid=''*'';'||chr(10)||

       'Alter system reset pga_aggregate_target scope=spfile sid=''*'';'||chr(10)||

       '-- SGA_MAX_SIZE ne doit pas etre superieur a MEMORY_TARGET'||chr(10)||

       'Alter system set sga_max_size='||to_char((qry_sga_target.value+

       greatest(qry_pga_target.value,qry_pga_alloc.value)))||' scope=spfile sid=''*'';' CMD_SQL

  from (select value from v$parameter where name='sga_target') qry_sga_target,

       (select value from v$parameter where name='pga_aggregate_target') qry_pga_target,

       (select value from v$pgastat where name='maximum PGA allocated') qry_pga_alloc,

       (select value from v$parameter where name='sga_max_size') qry_sga_max

;

 

Le script génère les commandes à lancer pour positionner les paramètres sus-cités.

Exemple:

SQL> Select '-- Memory Target = '||round(to_char((qry_sga_target.value+
  2          greatest(qry_pga_target.value,qry_pga_alloc.value)))/1024/1024)||' MB'||chr(10)||
  3         'Alter system set memory_target='||
  4    to_char((qry_sga_target.value+greatest(qry_pga_target.value,qry_pga_alloc.value)))||' scope=spfile sid=''*'';'||chr(10)||
  5         '-- Memory Max Target = '||round(to_char((qry_sga_max.value+
  6         greatest(qry_pga_target.value,qry_pga_alloc.value)))/1024/1024)||' MB'||chr(10)||
  7         'Alter system set memory_max_target='||
  8   to_char((qry_sga_max.value+greatest(qry_pga_target.value,qry_pga_alloc.value)))||' scope=spfile sid=''*'';'||chr(10)||
  9         'Alter system reset sga_target scope=spfile sid=''*'';'||chr(10)||
 10         'Alter system reset pga_aggregate_target scope=spfile sid=''*'';'||chr(10)||
 11         '-- SGA_MAX_SIZE ne doit pas etre superieur a MEMORY_TARGET'||chr(10)||
 12         'Alter system set sga_max_size='||to_char((qry_sga_target.value+
             greatest(qry_pga_target.value,qry_pga_alloc.value)))||' scope=spfile sid=''*'';' CMD_SQL
 13   14    from (select value from v$parameter where name='sga_target') qry_sga_target,
 15         (select value from v$parameter where name='pga_aggregate_target') qry_pga_target,
 16         (select value from v$pgastat where name='maximum PGA allocated') qry_pga_alloc,
 17         (select value from v$parameter where name='sga_max_size') qry_sga_max
 18  ;

CMD_SQL
--------------------------------------------------------------------------------
-- Memory Target = 5428 MB
Alter system set memory_target=5691155456 scope=spfile sid='*';
-- Memory Max Target = 6436 MB
Alter system set memory_max_target=6748120064 scope=spfile sid='*';
Alter system reset sga_target scope=spfile sid='*';
Alter system reset pga_aggregate_target scope=spfile sid='*';
-- SGA_MAX_SIZE ne doit pas etre superieur a MEMORY_TARGET
Alter system set sga_max_size=5691155456 scope=spfile sid='*';

Hope it helps...

ORA-04063: package body "SYS.DBMS_DATAPUMP" has errors

En exécutant un import avec datapump dans une base de données 11.2.0.3 j'ai rencontré l'erreur suivante:

UDI-04063: operation generated ORACLE error 4063
ORA-04063: package body "SYS.DBMS_DATAPUMP" comporte des erreurs
ORA-06508: PL/SQL : unite de programme nommee : "SYS.DBMS_DATAPUMP" introuvable
ORA-06512: a ligne 1

J'ai essayé de compiler les objets invalides, mais toujours le même problème:

SYS> @?/rdbms/admin/utlrp

SYS> alter package dbms_datapump compile body;

Avertissement : Corps de package modifie avec erreurs de compilation.

SYS> show errors
Erreurs pour PACKAGE BODY DBMS_DATAPUMP :

LINE/COL ERROR
-------- -----------------------------------------------------------------
4490/3 PL/SQL: Statement ignored
4490/3 PLS-00306: numero ou types d'arguments errones dans appel a
'GET_STATUS_INT'

Voir la liste des objets invalides:

select u.name owner, o.name object_name, o.status status
from sys.user$ u, sys.obj$ o
where u.user# = o.owner#
and o.status != 1
order by owner;

SYS DBMS_DATAPUMP 3
SYS _NEXT_OBJECT 0

Recharger donc datapump comme suit:

SYS>@?/rdbms/admin/dbmsdp.sql

Cela génère d'autres objets invalides, mais SYS.DBMS_DATAPUMP n'est plus dans la liste:

select u.name owner, o.name object_name, o.status status
from sys.user$ u, sys.obj$ o
where u.user# = o.owner#
and o.status != 1
order by owner;

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS KUPC$_EXIT 5
SYS KUPC$_SQL_FILE_JOB 5
SYS KUPC$_ESTIMATE_JOB 5
SYS KUPC$_LOAD_DATA 5
SYS KUPC$_LOAD_METADATA 5
SYS KUPC$_UNLOAD_DATA 5
SYS KUPC$_UNLOAD_METADATA 5
SYS KUPC$_RELEASE_FILES 5
SYS KUPC$_SEQUENTIAL_FILE 5
SYS KUPC$_DISK_FILE 5
SYS KUPC$_STOP_JOB 5
SYS KUPC$_START_JOB 5
SYS KUPC$_SET_PARAMETER 5

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS KUPC$_SET_PARALLEL 5
SYS KUPC$_OPEN 5
SYS KUPC$_METADATA_REMAP 5
SYS KUPC$_METADATA_TRANSFORM 5
SYS KUPC$_METADATA_FILTER 5
SYS KUPC$_LOG_ERROR 5
SYS KUPC$_LOG_ENTRY 5
SYS KUPC$_DATA_REMAP 5
SYS KUPC$_DATA_FILTER 5
SYS KUPC$_RESTART 5
SYS KUPC$_ADD_FILE 5

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS KUPC$_ADD_DEVICE 5
SYS KUPC$_MESSAGE 5
SYS KUPCC 5
SYS _NEXT_OBJECT 0
SYS DBMS_CUBE_EXP 5
SYS DBMS_AW_EXP 5
SYS DBMS_CDC_EXPDP 5
SYS DBMS_CDC_DPUTIL 5
SYS DBMS_DST 5
SYS DBMS_DATA_MINING 5
SYS DBMS_DM_IMP_INTERNAL 5

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS DBMS_DM_EXP_INTERNAL 5
SYS DBMS_DM_MODEL_IMP 5
SYS DBMS_DM_MODEL_EXP 5
SYS DBMS_DM_EXP_INTERNAL 5
SYS DMP_SEC 5
SYS DBMS_SQLTCB_INTERNAL 5
SYS DBMS_FILE_GROUP_UTL_INVOK 5
SYS DBMS_STREAMS_TABLESPACE_ADM 5
SYS DBMS_STREAMS_TBS_INT_INVOK 5
SYS DBMS_STREAMS_TBS_INT 5
SYS DBMS_STREAMS_DATAPUMP_UTIL 5

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS DBMS_STREAMS_DATAPUMP 5
SYS DBMS_STREAMS_RPC 5
SYS DBMS_LOGREP_IMP 5
SYS DBMS_LOGREP_EXP 5
SYS DBMS_STREAMS_MT 5
SYS DBMS_REPCAT_EXP 5
SYS DBMS_WRR_INTERNAL 5
SYS DBMS_SWRF_INTERNAL 5
SYS LOGSTDBY_INTERNAL 5
SYS DBMS_RULE_EXP_UTL 5
SYS DBMS_TTS 5

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS DBMS_PLUGTS 5
SYS KUPV$FT_INT 5
SYS KUPV$FT 5
SYS KUPD$DATA_INT 5
SYS KUPD$DATA 5
SYS KUPP$PROC 5
SYS KUPF$FILE 5
SYS KUPF$FILE_INT 5
SYS KUPM$MCP 5
SYS KUPW$WORKER 5
SYS KUPC$QUE_INT 5

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS KUPC$QUEUE_INT 5
SYS DBMS_DATAPUMP 5
SYS DBMS_METADATA_UTIL 5
SYS DBMS_METADATA_INT 5
SYS DBMS_METADATA 5
SYS DBMS_SCHED_MAIN_EXPORT 5
SYS DBMS_STREAMS_TBS_INT_INVOK 5
SYS KUPF$FILE_INT 5
SYS KUPC$_WORKER_GET_PWD 5
SYS KUPC$_WORKER_FILE_LIST 5
SYS KUPC$_WORKER_EXIT 5

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS KUPC$_WORKERERROR 5
SYS KUPC$_WORKER_LOG_ENTRY 5
SYS KUPC$_TABLE_DATA_ARRAY 5
SYS KUPC$_BAD_FILE 5
SYS KUPC$_DEVICE_IDENT 5
SYS KUPC$_WORKER_FILE 5
SYS KUPC$_GET_WORK 5
SYS KUPC$_ENCRYPTED_PWD 5
SYS KUPC$_FILE_LIST 5
SYS KUPC$_MASTERJOBINFO 5
SYS KUPC$_MASTERERROR 5

OWNER OBJECT_NAME STATUS
------------------------------ ------------------------------ ----------
SYS KUPC$_API_ACK 5
SYS KUPC$_POST_MT_INIT 5

Compiler les objets invalides:

SYS>@?/rdbms/admin/utlrp

Après la compilation:

select u.name owner, o.name object_name, o.status status
from sys.user$ u, sys.obj$ o
where u.user# = o.owner#
and o.status != 1
order by owner;

SYS _NEXT_OBJECT 0

Hope it helps...

ORA-15085: ASM disk "" has inconsistent sector size

J'ai vécu dernièrement un problème chez un client.
Les contrôleurs du SAN ont été mis à jour pour passer de la version IBM NSeries N7950T Data ONTAP 8.0.2P3 à la version 8.1.1.
Il faut dire que chez ce client nous utilisons Oracle Linux 5.5 with Unbreakable Enterprise Kernel 2.6.32. Comme produit oracle impacté, nous avons le Grid Infrastructure 11.2.0.3. 
Il faut aussi souligner que dans cet environnement ASMLIB est utilisé.

Après la mise à jour, aucun diskgroup ne pouvait être monté, et comme nous avons l'OCR et le voting disk dans ASM, le clusterware ne pouvait démarrer.

Nous avions pourtant quelques process du clusterware:

[oracle@node1 ~]$ ps -ef | grep d.bin
oracle 18807 1 0 17:43 ? 00:00:01 /ora01/logi/crs/crs_11g/bin/ocssd.bin
root 25069 1 0 15:19 ? 00:00:16 /ora01/logi/crs/crs_11g/bin/ohasd.bin reboot
oracle 27383 27339 0 17:51 pts/3 00:00:00 grep d.bin
oracle 31906 1 0 15:21 ? 00:00:00 /ora01/logi/crs/crs_11g/bin/mdnsd.bin
oracle 31921 1 0 15:21 ? 00:00:06 /ora01/logi/crs/crs_11g/bin/gpnpd.bin
oracle 31936 1 0 15:21 ? 00:00:14 /ora01/logi/crs/crs_11g/bin/gipcd.bin
root 31955 1 1 15:21 ? 00:02:21 /ora01/logi/crs/crs_11g/bin/osysmond.bin
[oracle@node1 ~]$

Dans le fichier $GRID_HOME/log/node1/cssd/ocssd.log, on avait l'information suivante:

2012-10-13 13:47:50.130: [ CSSD][1095424320]clssnmvDiskVerify: Successful discovery of 0 disks
2012-10-13 13:47:50.130: [ CSSD][1095424320]clssnmCompleteInitVFDiscovery: Completing initial voting file discovery
2012-10-13 13:47:50.130: [ CSSD][1095424320]clssnmvFindInitialConfigs: No voting files found

Lorsqu'on essayait de monter un diskgroup manuellement, on avait le message d'erreur:

SQL> alter diskgroup DATA11G mount;
alter diskgroup DATA11G mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15017: diskgroup "DATA11G" cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup
"DATA11G"
ORA-15085: ASM disk "" has inconsistent sector size.
ORA-15085: ASM disk "" has inconsistent sector size.
ORA-15085: ASM disk "" has inconsistent sector size.
ORA-15085: ASM disk "" has inconsistent sector size.
ORA-15085: ASM disk "" has inconsistent sector size.

Voila ce qu'oracle dit de ce message d'erreur:

======================================================
15085, 00000, "ASM disk \"%s\" has inconsistent sector size."
// *Cause: An attempt to mount a diskgroup failed because a disk reported
// inconsistent sector size value.
// *Action: Use disks with sector size consistent with Diskgroup sector size,
// or make sure the operating system can accurately report the disk
// sector size.
======================================================

Le problème est dû au fait qu'après la mise à jour des controleurs du SAN, ASMLIB a commencé à voir des blocks de 4k alors qu'avant la mise à jour il voyait des blocks de 512 bytes.

Conséquence, le Sector size est passé de 512 à 4096:

> for i in `ls /dev/oracleasm/disks/*`
> do
> blockdev --report $i
> done
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 838914048 /dev/oracleasm/disks/DISK_AD1
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 838914048 /dev/oracleasm/disks/DISK_AD2
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 838914048 /dev/oracleasm/disks/DISK_AD3
RO RA SSZ BSZ StartSec Size Device
rw 256 512 4096 0 838914048 /dev/oracleasm/disks/DISK_AD4

Les utilitaires tels que le ASM Metadata Dump Utility (AMDU) et KFED montrent qu'il n'y a pas de corruption.
Pour plus d'informations sur ces utilitaires, voir le document:
ASM tools used by Support : KFOD, KFED, AMDU [ID 1485597.1]

Pour tous les disques ASM de l'environnement, la signature ASM imprimée sur le disque semble correcte comme le montre la commande suivante:

[oracle@node1 ~]$ /usr/sbin/oracleasm listdisks |xargs -n 1 oracleasm querydisk -v -d
Disk "DISK_AD1" is a valid ASM disk on device [253, 4]
Disk "DISK_AD2" is a valid ASM disk on device [253, 5]
Disk "DISK_AD3" is a valid ASM disk on device [253, 6]
Disk "DISK_AD4" is a valid ASM disk on device [253, 16]

Après plusieurs échanges entre Oracle, IBM et NetApp, Oracle a décidé qu'on contourne la couche ASMLIB car les autres compagnies ne voulaient pas faire de retour arrière par rapport à leur mise à jour, trouvant cela trop risqué pour notre environnement.

Solution:

Pour résoudre le problème, nous avons été obligé de contourner ASMLIB.
À la suite de ce problème Oracle a créé le document suivant:
Alert: After SAN Firmware Upgrade, ASM Diskgroups ( Using ASMLIB) Cannot Be Mounted Due To ORA-15085: ASM disk "" has inconsistent sector size. (Doc ID 1500460.1)

Pour contourner Asmlib:

1) Démarrer le cluster en mode exclusive comme décrit dans le document:
=)> How to restore ASM based OCR after complete loss of the CRS diskgroup on Linux/Unix systems (Doc ID 1062983.1)

2) Désactiver ASMLIB comme décrit dans le document:
=)> V$ASM_DISK View Shows Both "ORCL:*" & "/dev/oracleasm/disks/*" Paths On 11.2 Release. (Doc ID 1410243.1)

3) Vérifier la configuration:

ASMCMD> dsget
parameter:/dev/oracleasm/disks/*
profile:ORCL:DISK_AD*,ORCL:DISK_FD*,ORCL:DISK_DD*
ASMCMD> dsset --profile '/dev/oracleasm/disks/*'
ASMCMD> dsget
parameter:/dev/oracleasm/disks/*
profile:/dev/oracleasm/disks/*
ASMCMD>

4) Monter les diskgroups:
ASMCMD> mount ocr_vote
ASMCMD> mount data
ASMCMD> mount fra
ASMCMD> mount data11g
ASMCMD> mount fra11g

5) Arrêter et démarrer le clusterware en mode normal (CRS)
Le clusterware a démarré correctement et tous les diskgroups ont été montés.

6) Vérifier les disques:
SQL> select path from v$asm_disk;
PATH
--------------------------------------------------------------------------------
/dev/oracleasm/disks/DISK_AD4
/dev/oracleasm/disks/DISK_AD2
dev/oracleasm/disks/DISK_AD3
/dev/oracleasm/disks/DISK_AD1

7)Vérifier les paramètres:
ASMCMD> dsget
parameter:/dev/oracleasm/disks/*
profile:/dev/oracleasm/disks/*
ASMCMD>

8) Nous avons exécuté  “check all norepair“ pour chaque diskgroup et aucune erreur n'a été rapportée:
SQL> alter diskgroup DATA check all norepair;
SQL> alter diskgroup DATA11G check all norepair;
SQL> alter diskgroup FRA check all norepair;
SQL> alter diskgroup FRA11G check all norepair;
SQL> alter diskgroup OCR_VOTE check all norepair;


Évidemment, nous nous sommes posé la question de savoir quelles sont les conséquences de désactiver ASMLIB dans un environnement Linux. À ce sujet, voici la réponse d'oracle support:

The benefits of using ASMLIB are described in the next document:
=)> How To Setup ASM on Linux Using ASMLIB Disks, Raw Devices or Block Devices? (Doc ID 580153.1)
=)> “Page #17”
======================================================
Therefore, by disabling ASMLIB those benefits will not be present.

Après ce problème, oracle a sorti un document dans "My Oracle Support" qui explique quoi faire pour éviter cette situation:
Alert: After SAN Firmware Upgrade, ASM Diskgroups ( Using ASMLIB) Cannot Be Mounted Due To ORA-15085: ASM disk "" has inconsistent sector size. (Doc ID 1500460.1)

Hope it helps...