Da li to pokusavas izvesti u nekom PL/SQL bloku koristeci EXECUTE IMMEDIATE?
'TRUNCATE TABLE tablename' bi trebao raditi bez problema, pa pretpostavljam da se greska mozda krije na nekom drugom mjestu u tvom PL/SQL kodu...
Pogledao sam na metalinku da li ima nešto o ovom problemu, pa sam našao da na je na tehničkom forumu postojala diskusija pre dve godine na sličnu temu. Nije nađeno rešenje, nije prijavljeno kao bag, a izgleda da se dešavalo na verzijama baze 9.2.0.4 i/ili 9.2.0.5
Kada god se neki ovakav bag prijavi, prvo što te pitaju: da li si primenio najnovije peč setove.
Dok sam se muvao po metalinku, primetio sam da se ora-00947 pojavljivala na bezveznim mestima kod daungrejdovanja sistemskih paketa (tj. nije primenjen odgovorajući CATPROC u odnosu na data dictionary), kao i kod ANALYZE TABLE komande za chained rows.
Ovo me je podsetilo na bag koji sam imao na SCO kada sam imamo OS Error - division by zero u upitu koji nije imao nikakvo deljenje, zato što je postojala statistika nad tabelom koja je bila u upitu.
Proveri da li su tabele baš potpuno iste na sistemu na kojem radi i na onom na kojem ne radi, da li su isti konstrejnti, da li na jednom postoji statistika nad tabelom/indeksima, a na drugom ne, da li postoje materijalizovani pogledi nad tabelom.
Naravno, primena peč seta koji je poslednji za tvoju bazu nikad nije na odmet.
Hvala Djoki i Dejanu na savetima i pomoci. Nije bilo do koda, bilo je do baze - na 9.2.0.4 (bez peč setova) je truncate pravio probleme, i proradio je kad su tabele koje su bile monitoring promenjene na nomonitoring, ali na kraju je baza upgade-ovana na 9.2.0.6 i sve je ok
Sigurna sam da znas da sam imala i ovde koga da pozovem, samo sam htela da se uverim da sam uradila sve sto mogu pre nego sto iscimam administratore :)