I have not worked with PowerPath (on Linux) - but, this may still be relevant. If powerpath utilizes the /etc/lvm.conf, you can customize (or optimize) for your specific array and have a script to name the devices whatever you want.

getuid_callout      "/usr/local/sbin/myscsi_id.sh %n"

In my environment, the WWN gets sent to a perl script which generates output based on a dictionary which maps an HDS serial number to a human-readable name and the LUN number.
360060e800571c900000071c9000005f7
71c9 = HDS01
70a7 = HDS02
In this case, the WWN multipath -ll -v2 would return
HDS01-05f7 dm-5 HITACHI,OPEN-V

James Nauer addressed this in a more subtle way, but I will try to respectfully be more blunt - you are doing it wrong.

The /dev/sd* device names are expected to change. When using a multi-pathing solution such as EMC's PowerPath or RHEL's native device-mapper-multipath, you should NEVER attempt to use the /dev/sd* device names. You can cause data corruption by doing so, as well as removing the redundancy of having multiple paths to the device for reliability and performance.

These multi-path solutions provide logical device names to the LUNs to provide 1) persistant device naming and 2) redundant access paths to the physical LUN. EMC PowerPath will provide logical device names that look like /dev/emcpowera which might point to example devices such as /dev/sdaa, /dev/sdab, /dev/sdac & /dev/sdad. There when when you read/write to /dev/emcpowera, that operation has 4 possible paths it could take. The number of devices depends upon the configuration of the backend SAN network, array and number of HBA interfaces.

In the case of RHEL's native device-mapper-multipath, the logical device will look something like /dev/mapper/mpatha. Both EMC PowerPath and Native Multi-Path perform equally well, though you will hear all kinds of bias and debates for each. It's all hogwash, they both perform very well and we have lots of customers using both very successfully. One advantage of Native Multi-Path is that you don't have to worry about updating to match the kernel. The "yum update kernel device-mapper-multipath" command will update both automatically.

Have you consulted our Oracle Recommend Practices Guides? I highly recommend them to properly tune your Oracle DB/RAC environment.

2014 - Deploying Oracle Database 12c on Red Hat Enterprise Linux 7- Recommended Practices
https://access.redhat.com/articles/1282303

2014 - Deploying Oracle Database 12c on Red Hat Enterprise Linux 6 - Recommended Practices
https://access.redhat.com/articles/725843

2013 - Deploying Oracle Database 11g R2 on Red Hat Enterprise Linux 6 - Recommended Practices
https://access.redhat.com/articles/395013

2013 - Deploying Oracle RAC 11g R2 Database on Red Hat Enterprise Linux 6 - Recommended Practices
https://access.redhat.com/articles/479093

Areas to focus on would include:

• use latest 6.6 errata (scheduler and THP improvements)
• multipath configuration
  *for performance use:
  • irqbalance (on by default)
  • numad
  • tuned ("tune-adm profile enterprise-storage")
  • configure hugepage sizes using the script in the guides

Having fun tuning your environment!!!

1. Set up multipath like below

defaults {
    find_multipaths yes
    user_friendly_names yes
}

# make your luns to human readable name
multipaths {
  multipath {
      wwid          360002ac000000000000000020000f8cc
        alias           lun1g001
    }
  multipath {
      wwid          360002ac000000000000000030000f8cc
        alias           lun1g002
    }

2. make your luns to raw device
/etc/udev/rules.d/60-raw.rules

ACTION=="add|change", ENV{DM_NAME}=="lun1g001", RUN+="/bin/raw /dev/raw/raw1 %N"
ACTION=="add|change", ENV{DM_NAME}=="lun1g002", RUN+="/bin/raw /dev/raw/raw2 %N"

3. optionally set devices permission.
/etc/udev/rules.d/12-dm-permission.rules

ENV{DM_UUID}=="mpath-?*", OWNER:="oracle", GROUP:="dba", MODE:="660"

4. Use your raw device to oracle rac raw device.