我看去年你的提问：https://www.modb.pro/issue/3124
其中也是报错ORA-17507，我翻了去年大佬给你的回复以及Oracle Mos，这个问题的几个相关文章大都描述当spfile位于sector为4096的asm磁盘上的时候发生：
Bug 16870214 : DB STARTUP FAILS WITH ORA-17510 IF SPFILE IS IN 4K SECTOR SIZE DISKGROUP
Bug 14626924 : NOT ABLE TO READ SPFILE FROM ASM DISKGROUP AND DISK WITH SECTOR SIZE OF 4096

我个人觉得大概率是因为上述几个问题，因为你的spfile所在asm磁盘sector为4k（这点可以很轻松可以通过os命令确认）。
如果确认的话，大概率命中了上述一些bug，解决办法也没那么复杂，但是可能会给以后管理带来一些不便：
rac spfile放到各自节点，不放在asm磁盘组，就是以后修改参数麻烦一些。

去年11月份是因为数据库备份提示ORA-17507，后来由于处理别的事情而没有来得及处理。
这几天碰上数据库运行速度特别慢，导致影响月结。跟踪几天进行分析awr提示参数有问题，我进行修改后提示这个错误。
按照您给的建议是把spfile放在每个节点服务器的硬盘上对吧，然后修改启动参数重服务器的硬盘读取spfile文件，而不是在asm上读取spfile文件？

workaround里也可以看看有没有sector size不是4k的，如果有不是4k的spfile放到相应asm磁盘组里也是可以的。

建议先确认一下是不是asm磁盘sector size是4k，如果是再进行处理，如果不是的话，还需要再排查。

磁盘组的sector size是512的话，你看看有没有磁盘是4k的扇区，要是也没有的话那跟bug描述的情形是不一样的，但是可以作为参考，试试spfile换个位置看看能不能正常。

compatible.rdbms的话，借用官方文档：Oracle® Database Storage Administrator’s Guide 11g Release 2 (11.2)原文：
For Oracle ASM in Oracle Database 11g, 10.1 is the default setting for the
COMPATIBLE.RDBMS attribute when using the SQL CREATE DISKGROUP statement,the ASMCMD mkdg command, ASMCA Create Disk Group page, and Oracle
Enterprise Manager Create Disk Group page.

1、截图中是共享硬盘，服务器本身硬盘的参数也是512

2、我看去年侯老师给的建议是重建pfile文件，但是我当时的spfile文件坏了，侯老师给的建议是通过查询系统参数重新写。
3、我的问题是我重新弄好了pfile文件并放在数据库服务器本机的硬盘上，重本地硬盘以pfile形式启动。
我的配置文件是写全局的还是单实例的？
我上传了个重新的配置文件，烦请帮忙看看有无错误

11g的话ORACLE_HOME/dbs下有一个init.ora的文件，指向了共享磁盘下的spfile，如果RAC各个实例把spfile创建在本地ORACLE_HOME/dbs目录下，那各个实例使用的spfile就独立了，修改参数的时候，就要在每个实例单独修改了，并且要指定alter system set … sid=‘xxx’;
19c rac的话spfile参数配置写到了ocr中，需要使用srvctl配置修改spfile路径了

老师，我在easdb1_mmon_318297.trc这个文件中查到有ora-17057的信息，详细有
Invalid Request:ORA-17507 lblksiz=16384 rcount=512 maxiosz=33554432
ksedsts()+465<-ksfd_osmvalsz()+105<-ksfd_osmvalio()+115<-ksfd_osmio()+792<-ksfd_io()+2782<-ksfdread()+581<-ksfdread_resilver()+61<-kspifisp()+649<-ksp_spfile_open()+775<-ksp_set_update_spfile()+1304<-kspset0()+1784<-ksp_bg_param_update()+350<-kmgs_perform_parameter_updates()+690
<-kmgs_parameter_update_timeout()+104<-ksb_run_managed_action()+384<-ksbcti()+852<-ksbabs()+1735<-kebm_mmon_main()+209<-ksbrdp()+1045<-opirip()+623<-opidrv()+603<-sou2o()+103<-opimai_real()+250<-ssthrdmain()+265<-main()+201<-__libc_start_main()+245Invalid Request:ORA-17507 lblksiz=16384 rcount=512 maxiosz=33554432
ksedsts()+465<-ksfd_osmvalsz()+105<-ksfd_osmvalio()+115<-ksfd_osmio()+792<-ksfd_io()+2782<-ksfdread()+581<-ksfdread_resilver()+61<-kspifisp()+649<-ksp_spfile_open()+775<-ksp_set_update_spfile()+1304<-kspset0()+1784<-ksp_bg_param_update()+350<-kmgs_perform_parameter_updates()+690
<-kmgs_parameter_update_timeout()+104<-ksb_run_managed_action()+384<-ksbcti()+852<-ksbabs()+1735<-kebm_mmon_main()+209<-ksbrdp()+1045<-opirip()+623<-opidrv()+603<-sou2o()+103<-opimai_real()+250<-ssthrdmain()+265<-main()+201<-__libc_start_main()+245Invalid Request:ORA-17507 lblksiz=16384 rcount=512 maxiosz=33554432
ksedsts()+465<-ksfd_osmvalsz()+105<-ksfd_osmvalio()+115<-ksfd_osmio()+792<-ksfd_io()+2782<-ksfdread()+581<-ksfdread_resilver()+61<-kspifisp()+649<-ksp_spfile_open()+775<-ksp_set_update_spfile()+1304<-kspset0()+1784<-ksp_bg_param_update()+350<-kmgs_perform_parameter_updates()+690
<-kmgs_parameter_update_timeout()+104<-ksb_run_managed_action()+384<-ksbcti()+852<-ksbabs()+1735<-kebm_mmon_main()+209<-ksbrdp()+1045<-opirip()+623<-opidrv()+603<-sou2o()+103<-opimai_real()+250<-ssthrdmain()+265<-main()+201<-__libc_start_main()+245**Invalid Request:ORA-17507 lblksiz=16384 rcount=512 maxiosz=33554432 **

这个日志能否说明ORA-17507 出现的原因呢？

可以从一些可读的call stack，看出来确实是操作spfile触发了这个问题，再深入，限于水平，看不出来啦。

ksp_spfile_open()+775<-ksp_set_update_spfile()

我觉得你可以尝试ssh到服务器端用sqlplus试试修改参数，看还会不会触发，看不用sqldeveloper是不是能规避这个问题。