I have to alter many columns in a Vertica table, and decided to drop the table altogether and create a new one. I also need 'undo' scripts ready to revert back the changes if needed (using mybatis migrations).
This is my plan:
rename mytable to mytable_backup
create mytable
create projection mytable_super (as select from mytable)
--undo
drop mytable if exists
rename mytable_backup to mytable
The original mytable was also created with a projection. The above script gives an error saying projection already exists.
DBCException: SQL Error [4482] [42710]: [Vertica][VJDBC](4482) ROLLBACK: Projection with base name "mytable_super" already exists
I believe when I rename the original table, the underlying projection is not being renamed.
What is the best way to rename a table with projections in vertica? Or what is the best way to back up a table and revert back?
You'll need to rename the projections as well.
alter projection mytable_super rename to mytable_super_backup;
For renaming a table, the above answer is the one.
One way to rename a projection, would be to get the projection inside a SQL file. For example:
select CONCAT(CONCAT(projection_schema,'.'),projection_name) from projections where projection_schema like '%one_table%'
Then modify it into the following SQL and execute it (and don't forget to run refresh):
https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/AdministratorsGuide/Projections/UpdatingProjectionsUsingRefresh.htm
Once you have the SQL, you can do \i /path/of/sql (inside vertica shell) or you can /opt/vertica/bin/vsql -f /path/to/sql/that.sql -U vertica_user -w vertica_passwd
Related
Suppose I have an existing schema (s1) with the following tables:
s1.table1
s1.table2
I would like to clone this schema to a new schema (s2) i.e.:
s2.table1
s2.table2
How can I achieve this?
The purpose is for testing without touching the original data.
I'm aware of the EXPORT command but it appears to be able to only export 1 table at a time.
You can copy a table's definition to a new table, without copying the data in the original table using CREATE TABLE ... LIKE:
CREATE TABLE s2.table1 (LIKE s1.table1 INCLUDING ALL);
CREATE TABLE s2.table2 (LIKE s1.table2 INCLUDING ALL);
You can then copy the rows from the original table if needed:
INSERT INTO s2.table1 SELECT * FROM s1.table1;
INSERT INTO s2.table2 SELECT * FROM s1.table2;
I need sone help in PL/SQl.
So my problem is, the following problem:
There is a table called: temp_table and I need to create a temp_table without drop/truncate option. It needs because all the time a table's data changing.
So I know its weird, but this is necessary for my daily job.
The script work like this:
The script does a text import to table, and the table is given. It use a dblink to connect the database. It works, but all the time I have to use DROP. But I need ( if its possible) to create an existing table without drop/truncate.
Can someone help me?
Thanks a lot.
Sorry for no sql code, but i think it doesn't necessary.
I think the concept you want is the external table. With external tables the data resides in OS files, such as CSVs. This allows us to swap data sets without dropping the table.
Find out more.
I take it you want to drop the table because you want to reload it, but you also want there to be as close to constant up-time as possible?
I would create two temp tables. You already have one called:
temp_table
Create another called:
temp_table_new
Load your new data into temp_table_new, then run a rename on it like so:
RENAME TABLE temp_table TO temp_table_old
temp_table_new TO temp_table
Then
drop table temp_table_old
This will be super fast, have very little downtime, and allow you to have the functionality you've described.
I want to create a table (lets say table_copy) which has same columns as other table (lets call it table_original) in Oracle database, so the query will be like this :
create table table_copy as (select * from table_original where 1=0);
This will create a table, but the constraints of table_original are not copied to table_copy, so what should be done in this case?
Only NOT NULL constraints are copied using Create Table As Syntax (CTAS). Others should be created manually.
You might however query data dictionary view to see the definitions of constraints and implement them on your new table using PL/SQL.
The other tool that might be helpful is Oracle Data Pump. You could import the table using REMAP_TABLE option specifying the name for the new table.
Use a database tool to extract the DDL needed for the constraints (SQL Developer does the job). Edit the resulting script to match the name of the new class.
Execute the script.
If you need to do this programmatically you can use a statement like this:
DBMS_METADATA.GET_DDL('TABLE','PERSON') from DUAL;
I have a database schema which is identical in files 1.sqlitedb through n.sqlitedb. I use a view to 'merge' all of the databases. My question is: when i insert into the view, into which database does the data get inserted into? Is there any way to control which gets the data? The way that i need to split the data depends on the data itself. Essentially, i use the first letter of a field to determine the file that it gets inserted into. Any help would be appreciated. Thanks!
Writing to views is NOT supported for SQLite like it is with other dbs.
http://www.sqlite.org/omitted.html
In order to achieve similar functionality, one must create triggers to do the necessary work.
We need to implement instead of trigger on the view (VIEW_NAME) . So when insert/update happens view . we can insert update underlying object (TABLE_NAME) in the trigger body.
CREATE TRIGGER trigger_name instead of INSERT on VIEW_NAME
BEGIN
insert into TABLE_NAME ( col1 ,col2 ) values ( :new.col1, :new.col2);
END;
I'm not sure I understand your question, but have you looked into using the ATTACH DATABASE command? It allows you connect separate database files to a single database. You can control INSERTs into a specific database by prefixing the database name (INSERT INTO db1.Table).
http://www.sqlite.org/lang_attach.html
I currently have 2 schemas, A and B.
B has a table, and A executes selects inserts and updates on it.
In our sql scripts, we have granted permissions to A so it can complete its tasks.
grant select on B.thetable to A
etc,etc
Now, table 'thetable' is dropped and another table is renamed to B at least once a day.
rename someothertable to thetable
After doing this, we get an error when A executes a select on B.thetable.
ORA-00942: table or view does not exist
Is it possible that after executing the drop + rename operations, grants are lost as well?
Do we have to assign permissions once again ?
update
someothertable has no grants.
update2
The daily process that inserts data into 'thetable' executes a commit every N insertions, so were not able to execute any rollback. That's why we use 2 tables.
Thanks in advance
Yes, once you drop the table, the grant is also dropped.
You could try to create a VIEW selecting from thetable and granting SELECT on that.
Your strategy of dropping a table regularly does not sound quite right to me though. Why do you have to do this?
EDIT
There are better ways than dropping the table every day.
Add another column to thetable that states if the row is valid.
Put an index on that column (or extend your existing index that you use to select from that table).
Add another condition to your queries to only consider "valid" rows or create a view to handle that.
When importing data, set the new rows to "new". Once the import is done, you can delete all "valid" rows and set the "new" rows to "valid" in a single transaction.
If the import fails, you can just rollback your transaction.
Perhaps the process that renames the table should also execute a procedure that does your grants for you? You could even get fancy and query the dictionary for existing grants and apply those to the renamed table.
No :
"Oracle Database automatically transfers integrity constraints, indexes, and grants on the old object to the new object."
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_9019.htm#SQLRF01608
You must have another problem
Another approach would be to use a temporary table for the work you're doing. After all, it sounds like it is just the data is transitory, at least in that table, and you wouldn't keep having to reapply the grants each time you had a new set of data/create the new table