Du säger att CAMPO47 är mycket selektivt. Men du filtrerar bara på IS NOT NULL. Så det spelar ingen roll hur många distinkta värden den har, optimeraren kommer inte att använda den som ingångspunkt.
Och hur selektivt är det? Som du kan se av kardinaliteterna i förklaringsplanen, hittar du 12856 rader i din tabell om du väljer STATO='SC'. 12702 av de uppenbara raderna har CAMPO47 med ett värde, så endast 154 rader filtreras bort av testet för nullitet. Om optimeraren hade ökat för indexet på CAMPO47, hur många rader skulle det ha returnerat? Förmodligen mycket mer.
Optimeraren kan bara använda ett heapindex för att komma åt rader i en tabell. (Mekanismen är annorlunda för bitmappsindex när de tillämpar en stjärnomvandling). Så om du tror att de ytterligare tabellåtkomsterna är en olidlig börda så har du ett alternativ:ett sammansatt index. Om STATO verkligen är oselektiv (relativt få rader) är du förmodligen säker på att ersätta det befintliga indexet med ett på (STATO, CAMPO47).
Det finns ett gammalt knep för att knuffa databasen till att använda ett index för att komma åt IS NOT NULL-operationer, och det är att använda en operand som bara kan vara sann där kolumnen innehåller ett värde. Till exempel, något sånt här för strängkolumner (jag antar att något som heter CAMPO47 bara måste vara en sträng):
AND campo47 >= chr(0)
Det kommer att matcha alla kolumner som innehåller ett eller flera ascii-tecken. Inte säker på om det kommer att leda till "tvåindex"-optimeringen du beskriver men det är värt ett försök. (Jag skulle testa detta själv men jag har inte tillgång till en Oracle-databas just nu, och SQL Fiddle slungade när jag försökte titta på Explain Plan)