Opa, então : 1) Por via de regra em não havendo bugs e/ou exigências do seu Aplicativo que proíbam, ** SEMPRE ** é melhor vc ter o parâmetro de COMPATIBILITY setado para o versão física real : setar para valor inferior pode te Bloquear o uso de alguma feature da versão real que seja importante no seu ambiente....
2) Bom, vc não diz se vc tá usando MULTIPATH ou não, mas pelo que vc descreve entendo que não... No caso de single-path devices, sim é normal que os paths mudem porque a busca por devices não segue necessariamente a mesma ordem - inclusive, no caso de filesystems montados nos devices, a idéia é usar o UUID, o "stamp" físico que esse sim não muda, veja https://ubuntuforums.org/showthread.php?t=1621961 para um exemplo... Muito bem, falando sobre o ASM, justamente a função do asmlib é "dar um nome", um "id" único para cada disco em storage, que vai ser "carimbado" no disco físico e vai persistir após reboots - https://community.oracle.com/thread/3893102 explica exatamente isso... Então não, SE corretamente implementado e configurado o asmlib, o fato (natural) de que paths podem mudar não interferirá... Lembrando que para algumas distros mais recentes de Linux vc não tem mais asmlib pra elas, a alternativa aí é usar o UDEV, https://bartsjerps.wordpress.com/2014/07/01/linux-udev-create-asm-disk-volumes/ fala sobre... 3) Não, eu não vejo *** PROBLEMA ALGUM *** em se ter algumas tablespaces em ASM e algumas em filesystem ou RAW, de forma alguma.... Faça um teste no seu ambiente HOMO e vc vai ver que o overhead do ASM é ** minimo ** , a performance deve ser basicamente A MESMA ok ? A única coisa, Óbvio, é que no instante em que vc passou algum datafile pro ASM, o banco que contém esse datafile passou a ter uma DEPENDÊNCIA do ASm - cabe a vc se assegurar que após reboots o ASM é inicializado ANTES que os databases que dependem dele, que o ASM está sendo monitorado... Óbvio, se ASM cair ou não subir, os bancos que dele dependem NÃO SOBEM ou dão algum erro, logicamente... O procedimento pretendido é razoável, realmente o RMAN possui SIM capacidade de backupear para ASM - ainda com o RMAN vc tem outras possibilidades além do BACKUP COPY, como um copy datafile '/pathdodatafile/nomedodatafile.dbf' to '+NOMEDODG'; , ou um simples ALTER DATABASE MOVE DATAFILE 'pathdodatafile.dbf' TO '+DATA'; - a performance desses comandos deve ser basicamente a mesma, já que vc está lendo da fonte não-ASM e gravando no ASM com todos, mas teste aí.... ùnica coisa é que vc diz que está usando a restrita e capadinha Standard Edition, então afaik nada de backup com paralelismo/múltiplos canais de gravação pra vc.... Aliás, um movimento Extremamente Corajoso rodar base de vários Terabytes em Standard e portanto não ter Paralelismo, Particionamento, Compactação.... Uau... []s Chiappa
