Is it possible to create a hive view on top of a nonexistent hive table or views?. This ability will help us deploy the hive DDL without any order at the time of refresh (migrating tables or views from one environment to another). In our environment, we have views built on top of another view. If we deploy them in any order, with the default setup some of the views may fail saying the underlying table/view doesn't exist. Looking to see if we can turn off the metadata lookup from hive metastore so that the type checks are not done at the time of view creation. It can be enforced after the deployment or at the time of querying the view for data retrieval because by that time all the views/tables will be completely deployed and there won't be any type checking related errors.
I checked on the internet for pointers but I couldn't find any. Any suggestions in this regard will be helpful to us.
Thanks in advance.
Add IF NOT EXISTS to all create statements and run all several times until errors disappear.
If executed 2 times in the wrong order like this, second run will succeed without any error:
drop view if exists my_view;
create view if not exists my_view as select from table1; --fails first time, succeeds on second run
drop table if exists table1;
create table if not exists table1(id int);
Related
I worked on an App using my personal workspace. Exported the same and later installed it on a Developer Team workspace.
Several of my pages are getting the ORA-00942: table or view does not exist while running, which doesn't make sense since the tables do exist (I tested this using the 'SQL Commands' option).
Funny thing is that the same code I'm using is actually applied on a different app within the same workspace and it runs perfectly.
Is this normal behavior? Might be due to workspace's configuration?
Thanks!
It could be a "permissions" issue:
http://www.dba-oracle.com/sf_ora_00942_table_or_view_does_not_exist.htm
Answer: There are several common operations that cause a ORA-00942
error:
Table owner name not specified when logged-in as a non-creator of the table.
ORA-00942 on table import (imp or impdp).
ORA-00942 on materialized view refresh.
...
This ORA-00942 error on insert is common when the user you are
signed-on as does not have permission to see the table!
Either make the table public and grant DML privileges:
connect myuser/mypass
create public synonym testtable for myuser.testtable
grant insert, select, update, delete on mytable to public;
Also, review the various replies to this thread. For example:
https://stackoverflow.com/a/36165446/421195
Because this post is the top one found on stackoverflow when searching
for "ORA-00942: table or view does not exist insert", I want to
mention another possible cause of this error (at least in Oracle 12c):
a table uses a sequence to set a default value and the user executing
the insert query does not have select privilege on the sequence. This
was my problem and it took me an unnecessarily long time to figure it
out.
First thing I would check is the parsing schema for the application - see Shared Components -> Security Attributes.
If this is not the same between the two instances of your application, that's the likely explanation.
Something failed while we were swapping disks for our ClickHouse database. When ClickHouse started, I had to attach all the tables as they were not there via ATTACH TABLE IF NOT EXISTS ....
Is there a way to do the same for materialized views? I couldn't find a way how to do that and when I try to create it from scratch (CREATE MATERIALIZED VIEW IF NOT EXISTS ..., ClickHouse says:
Data directory for table already containing data parts - probably it
was unclean DROP table or manual intervention. You must either clear
directory by hand or use ATTACH TABLE instead of CREATE TABLE if you
need to use that parts.
So the files are still there but dunno how to attach the view.
You need to attach the ".inner." table first.
Materialized views do not store data, they create a special table with the engine that you choose when you create the view. The name of that table is ".inner.the_name_of_the_view".
So you need to attach that table first, and then attach the materialized view.
When attaching other tables and restarting the ClickHouse server, the views got attached automatically. I was trying to attach .inner tables too but it didn't let me.
I have an external hive table and I would like to refresh the data files on a daily basis. What is the recommended way to do this?
If I just overwrite the files, and if we are unlucky enough to have some other hive queries to execute in parallel against this table, what will happen to those queries? Will they just fail? Or will my HDFS operations fail? Or will they block until the queries complete?
If availability is a concern and space isn't an issue, you can do the following:
Make a synonym for the external table. Make sure all queries use this synonym when accessing the table.
When loading new data, load it to a new table with a different name.
When the load is complete, point the synonym to the newly loaded table.
After an appropriate length of time (long enough for any running queries to finish), drop the previous table.
First of all.. if you are accessing any table it may have two types of locks:
exclusive(if data is getting added) and shared(if data is getting read)..
so if you insert overwrite and add data into the table then at that time if you access the table with other queries, they wont get executed because there will be an exclusive lock on it and once the insert overwrite query completes then you may access the table.
Please refer to the following link:
https://cwiki.apache.org/confluence/display/Hive/Locking
In my Oracle instance I have a table. It existed just fine for many years without problems, I run thousands of queries per day on it (through my software), mostly selects and inserts, with rare (once-a-week) updates.
Today, a week after the last update, I ran an update against it and it failed with an ORA-00942: table or view does not exist.
I am the owner of that table. I'm pretty sure that database didn't change much during the week, certainly not this table.
I can select from it just fine: select * from table_x, but updates and inserts fail: insert into table_x select * from table_x where 1 = 0 with the weird ORA-00942.
Since I'm the owner, the usual visibility and privilege problems don't seem to apply, and googling, sadly, doesn't help. I'm sure I'm missing something really simple, so any suggestions are very welcome.
How did I make an Oracle table read-only (or invisible) for myself (the owner)?
It's partitioned (not sure if that helps). It's about 50GB in size, half of that indexes (not sure if that helps either).
EDIT: Here's a screenshot of the sample statement from PL/SQL Developer:
Once I ran the same situation, according to the trace file and little googling which referenced to Materialized View Log which is associated with master table.
Use the following command to drop the materialized view log
DROP MATERIALIZED VIEW LOG ON <table_x>
In context of Oracle 9i database, usually for a view to be created an underlying base table is mandatory, however this constraint can be violated if the FORCED clause is used while creating the view.
What is the significance of these views if their base tables does not exist?
In which conditions these views will be of help?
you would use the FORCE keyword if you are creating several views that reference each other and you don't want to spend time to determine in which order they should be created.
See also:
streamlining creating of packages and views
On a large project this can be very useful: I create a table, someone else creates a packaged function, and you create a view that accesses the table and the packaged function. We then all put our DDL into the source control / release system and the DBA installs all the code on the test / production system. The FORCE keyword ensures that the view gets created, though possibly in an invalid state, even if its DDL is run before the table and/or package DDL.