Realmente uma coisa feia, até porque (** imagino **) existe um Roteiro muito específico de como trabalhar com standby aí na sua Empresa, não importa quem seja o cliente e quem seja o DBA, né não ?? è o caso de pegra o sujeitinho que aprontou uma dessa e dar uma surra com um gato morto até o gato miar.... G-suis....
Bom, primeira coisa se o animalzinho chegou mesmo a criar a tablespace manualmente esse dicionário virou uma zona só, vou dar o que penso ser o procedimento mas não garanto coisa nenhuma : em tese o que eu vou dizer deveria funcionar, mas é aquele negócio, procedimentos fora do padrão são o VEÍCULO para bugs, até porque os desenvolvedores da Oracle não vão perder tempo testando profundamente alguma coisa que não devia acontecer, né não ?? Muito bem : como eu tinha dito penso que a primeira coisa a se fazer é PARAR o processo de recover do banco standby (já que com as incongruências em questão FATALMENTE ele só tá gastando CPU à toa, não vai conseguir aplicar coisa nenhuma)... Isso feito, cheque se as tablespaces e datafiles tão IDÊNTICOS no PROD e no STANDBY, com uma consulta tipo : select T.TS#, T.name TABLESPACE_NAME, D.FILE#, D.NAME FILE_NAME, D.BYTES, D.BLOCKS, D.STATUS FROM V$TABLESPACE T, V$DATAFILE D WHERE T.TS# = D.TS# ORDER BY 1,3; Isso vai te dizer se o RESTO das tablespaces e datafiles tão sincronizados certinho, E qual é a desse tal arquivo $ORACLE_HOME/dbs/UNNAMED00167.dbf : de repente pode até ser que ele foi criado por alguém mas no momento não está sendo usado por tablespace nenhuma, sabe-se lá.... Feito isso, SE a tal tablespace adicionada no Primary já existe no standby (talvez criada com esse datafile loucão aí no ORACLE_HOME), drope ela no standby, remove esse arquivo doido E os demais que se relacionam com essa tablespace e copie os datafiles pro standby... O procedimento creio que ser esse mesmo, ie : bota em modo de backup, copia, tira de modo backup.... COM ISSO, quando futuramente vc restartar o processo de recovery do standby o RDBMS deve ser capaz de reconhecer os datafiles que vc trouxe do primary, atualizar o dicionário de dados E o controlfile, registrando assim corretamente a tablespace... Porém, antes de restartar o processo de recover, dá uma PROCURADA no ASM e confirme se os archives que originalmente continham as sequences de redo necessárias ainda estão em disco ou não : como outros colegas apontaram, de repente eles podem estar em uma pasta com a data diferente, talvez : usa o FIND no asmcmd.... []s Chiappa
