Nope : até onde eu sei não há NENHUM parâmetro que controle o tamanho máximo do listener.log no RDBMS em si : pode olhar na Documentação que afaik vc não achará nenhum...
O que ocorre é que TANTO o Sistema Operacional (principalmente em controles de kernel) quanto o hardware quanto as camadas de software que controlam / acessam o hardware (ie, FILESYSTEM) possuem seus limites... Outro ponto *** crucial *** é que o software de RDBMS Oracle ainda tem (ao menos enquanto as versões anteriores a 12cR2 não forem Totalmente Aposentadas) que incluir libs/headers em 32 bits em SOs de 32-bits por questões de compatibilidade, e com software de 32 bits as libraries da linguagem C impõem 32 bits como limite máximo para representar um tamanho de arquivo... Da mesma forma, como já dito acima, diversos filesystems assumiam 32 bits também como tamanho máximo, o que resultava em 4GB (ou 2 GB, dependendo do número de bytes usados para controlar tamanho de arquivo), cfrme https://en.wikipedia.org/wiki/Large_file_support mostra .... ==> Sabendo disso tudo, afaik a Oracle simplesmente assumiu (sem prejuízo para os OUTROS limites externo, é claro) 4GB como tamanho máximo até antes da versão 12cR2 de um arquivo individual, é hard-coded mesmo... só não sei se no 12cR2 foi introduzido algum parâmetro (oculto que seja) alterando isso, que eu saiba não... ==> o que vc tem que fazer (não só pro LISTENER.LOG mas TAMBÉM pro alert.log e ** todos ** os outros arquivos de log gerados no seu ambiente, como logs de Agent, de ASM, de Clusterware, todos os logs enfim) é implementar algum rotina de ROTATE, ie, um JOB qquer que MUITO ANTES do arquivo chegar perto dos 4 GB (ou menos, se seu SO/filesystem/bitsize/whatever tem restrições menores) salve o conteúdo do log file em questão com outro nome, o compacte E o salve/arquive nalgum lugar para que seja usado se necessário no futuro....SIM, se vc não fizer isso é bem provável vc ter algum tipo de abort no listener, OU então o lsitener passar a rodar sem gerar log nenhum, causando a perda completa dos seus elementos de audit/controle de conexão relacionados ao listener... Especificamente para o listener.log um exemplo da técnica pode ser https://blog.dbi-services.com/oracle-12-2-how-to-rotate-the-12-2-listener-log-diag_adr_enabled_listener-off/ , que usa a técnica de desabilitar temporariamente o log para que o file handle seja fechado e o arquivo de log possa ser movido/renomeado... Só tomar cuidado porque, tal como a nota metalink "How To Change the Listener Log Filename Without Stopping the Listener" (Doc ID 135063.1) nos lembra, se o ADR estiver ligado vc pode levar um erro de "TNS-01251: Cannot set trace/log directory under ADR, o ADR tem que ser temporariamente desligado antes de se fazer isso... []s Chiappa OBS : não tem a ver com o que vc perguntou, mas relembro que (ao contrário dos arquivos de LOG) para os arquivos de trace aí SIM existem parâmetros que controlam o tamanho máximo deles e (em alguns casos) eles podem ser Múltiplos, ie : se um arquivo de trace chegou no limite que vc especificou, um outro arquivo é aberto.... Essa última técnica de vc ter múltiplos arquivos de resultado/diagnóstico, cada um respeitando o limite máximo que vc indicou, não funciona porém para os aqruivos de LOG, via de regra eles são únicos (ie, vc só tem UM listener.log pro teu listener, UM alert.log pra sua instância, etc)...
