Embora já existam várias respostas descrevendo corretamente o comportamento de char , acho que é preciso dizer que você não deve usá-lo exceto em três situações específicas:

1. Você está criando um arquivo ou relatório de tamanho fixo e atribuindo um valor não nulo a um char evita a necessidade de codificar um rpad() expressão. Por exemplo, se firstname e lastname ambos são definidos como char(20) , então firstname || lastname é uma forma mais curta de escrever rpad(firstname,20) || rpad(lastname,20) para criar Chuck Norris .
2. Você precisa distinguir entre a string vazia explícita '' e null . Normalmente eles são a mesma coisa no Oracle, mas atribuindo '' para um char value acionará seu comportamento de preenchimento em branco enquanto null não vai, então, se é importante dizer a diferença, e eu realmente não consigo pensar em uma razão para isso, então você tem uma maneira de fazer isso.
3. Seu código é portado de (ou precisa ser compatível com) algum outro sistema que requer preenchimento em branco por motivos legados. Nesse caso, você está preso a isso e tem minha simpatia.

Não há realmente nenhuma razão para usar char apenas porque algum comprimento é fixo (por exemplo, um Y/N bandeira ou um código de moeda ISO, como 'USD' ). Não é mais eficiente, não economiza espaço (não há indicador de comprimento mítico para um varchar2 , há apenas uma sobrecarga de preenchimento em branco para char ), e isso não impede ninguém de inserir valores mais curtos. (Se você digitar 'ZZ ' em seu char(3) coluna de moeda, ela será armazenada como 'ZZ ' .) Não é nem mesmo compatível com versões anteriores do Oracle que uma vez dependiam dele, porque nunca houve um.

E o contágio pode se espalhar, pois (seguindo a melhor prática) você pode ancorar uma declaração de variável usando algo como sales.currency%type . Agora sua l_sale_currency variável é um char furtivo que será invisivelmente preenchido em branco para valores mais curtos (ou '' ), abrindo a porta para bugs obscuros onde l_sale_currency não é igual a l_refund_currency mesmo que você tenha atribuído 'ZZ ' a ambos.

Alguns argumentam que char(n) (onde n é algum comprimento de caractere) indica que os valores devem ser n caracteres longos, e esta é uma forma de auto-documentação. Mas certamente se você leva a sério um formato de 3 caracteres (códigos de país ISO-Alpha-3 em vez de ISO-Alpha-2, por exemplo), você não definiria uma restrição para impor a regra, em vez de deixar os desenvolvedores olharem para a char(3) tipo de dados e tirar suas próprias conclusões?

CHAR foi introduzido no Oracle 6 por, tenho certeza, motivos de compatibilidade ANSI. Provavelmente existem clientes em potencial decidindo qual produto de banco de dados comprar e compatibilidade com ANSI está na lista de verificação (ou costumava estar na época) e CHAR com preenchimento em branco é definido no padrão ANSI, portanto, a Oracle precisa fornecê-lo. Você não deve realmente usá-lo.