views:

1078

answers:

2

An external DB admin guy exported a production database and imported it into test environment. We are using Oracle 9.2. Majority of imported database objects (tables, views, idexes, packages,...) works fine, but we have problems with three specific tables: we can do SELECT,UPDATE, DELETE on those tables, but we can not create views on this tables.

In other words, the folowing works:

 create or replace view v_test_view as select 1 x from dual; // we can create views
 create or replace view v_test_view  as select 1 x from someTable;
 select * from problematicTable; // we can select data from problematic table

But this does NOT work:

 create or replace view v_test_view  as select 1 x from problematicTable;
--> ORA-01031: insufficient privileges

Background info:

  • db admin used import/export utility to copy the database schema
  • the version of production and test Oracle are not exactly the same (production is 9.2.0.8, test is 9.2.0.7)
  • after the initial import was done, the problematicTable was visible in object catalog (and database development tools), but when trying to SELECT from this table, we got back "invalid identifier". After that, the tables were re-imported and now we are able to SELECT from the, but not to create views on them

Any ideas?

UPDATE: It looks like the situation is even more strange. When using one oracle session we can SELECT data from this table, in another Oracle session (using the same user to login!), we are getting "ORA-00904: invalid identifier"

UPDATE#2: The export data that was used to import from was sucesfully used to import data to another test environment (lets call it TEST1) which is located on the same instace of Oracle as the problematic one (TEST2). The difference beteween those two environments are that TEST1 uses the same user (schema name) as the production, but TEST2 uses another user (soo the objects were imported into another schema name). The problematicTables do not have any special security properties that are different from the tables that works OK.

Matra

+3  A: 

Is the user creating the view granted select on the problematic table via a ROLE? If so, try giving an explicit grant on the table.

From Oracle:

"In order to create a view in a schema, that schema must have the privileges necessary to either select, insert, update, or delete rows from all the tables or views on which the view is based. The view owner must be granted these privileges directly, rather than through a role. The reason is that privileges granted to roles cannot be inherited via objects."

DCookie
We are not using special ROLES. select * from SESSION_ROLES returns CONNECT, PLUSTRACE, RESOURCE. The user is owner of the schema. See also UPDATE#2.
Is there anything these problematic tables have in common? After the import, do you get the same error if you manually execute the create view statement? Shots in the dark...
DCookie
They are not different from other tables which were imported OK. Common thing: table names start with 'A' (but there are other 'A' tables that are OK). Those tables were one of the first created in this DB few years ago. I've tried to re-create views manually (see original question), but no sucess.
Is it feasible to recreate the tables as a CREATE TABLE...AS SELECT and create the view on the new table?
DCookie
I suppose you've checked for synonyms?
DCookie
DCookie, I do not know what you mean with "check for synonyms". Yes, we are using 26 synonyms, but they are not related to problematic table. They are pointing to 26 tables in some other (third) schema. We will try to re-import the whole database again to see if anything changes.
Perhaps if you provided the exact, complete table create statements for the problem tables and one that works we might be able to do more than guess... I'd be willing to wager there IS something different about these tables.
DCookie
I can not provide the source for the CREATE table. The table contains 59 columns, most of them are VARCHAR2, we have 1 DATE and 2 NUMBERS. All columns are nullable. The table has 6 indexes. 1 one them is a function index which converts one of the VARCHARs to DATE.
There is also BEFORE INSERT OR UPDATE triger which uses a function to calculate the value of two of calculated columns. Currently, we are re-importing the schema (it will taks a while) to see if anything changes, I'll post the update when we are finished.
BTW: Other tables that work have similar structure. Some of them have much larger number of columns (cca 200).
I guess I'd strip the table down to it's bare implementation without any indexes. If that fails, create a copy of it as I suggested earlier. Do the 3 tables all have a function based index?
DCookie
Both problematic and non-problematic tables have function based indexes. They all use the same function.
DCookie, thanks for the suggestions about re-creating the tables. It helped us to drill into the right dirrection
A: 

It looks like there was something wrong with the import. So what our DB admin did to fix the problem was:

  • drop the problematic tables
  • reimport the structure of the problematic tables (columns, constraints, indexes)
  • after the structure was re-created he re-imported the data
  • he also played with the CREATE TABLE AS SELECT to copy the data back and forth

When he was re-creating the table structure he discovered, that the current schema run out of free space (it was not set to auto grow). The strange thing is, that the first import did not complain about insufficient space.

So in theory is that insufficeint space was the reason for corrupted data dictionary.

I thought about pointing you at the alert log for the instance, but thought "nah, probably nothing there". Out of space errors should show up in there.
DCookie
The strange thing is that there was no error/warning in the import log. Thanks anyway.