I am relatively new to SQL and only dabble with it when it is required. I have done some research on this but have limited success. I need to remove the tablespace references from the code. The settings already exist in the database for a default tablespace. By the way it is an Oracle database.
If I have these lines of code:
EXECUTE IMMEDIATE 'CREATE TABLE RAND_CATEGORY(
-------- insert random vars ---------------
CONSTRAINT RAND_CATEGORY PRIMARY KEY(cat_id,ver_num)
USING INDEX TABLESPACE VG_NDX ENABLE
)TABLESPACE VG_DATA';
Here's what I have so far:
EXECUTE IMMEDIATE 'CREATE TABLE RAND_CATEGORY(
-------- insert random vars ---------------
CONSTRAINT RAND_CATEGORY PRIMARY KEY(cat_id,ver_num)
USING INDEX TABLESPACE VG_NDX ENABLE
)';
My question is, should I remove the entire line:
USING INDEX TABLESPACE VG_NDX ENABLE
Or should I just remove the "TABLESPACE VG_NDX" and leave it as:
USING INDEX ENABLE
Keep in mind that I am new to this and I just need help with this. I have been learning SQL for the past 2 weeks and tablespaces are a bit funky to me. Thanks in advance! :D
Read this document:
http://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_7003.htm
It provides a good overview of what tablespaces are and should solve the issue.
The USING INDEX clause allow to have more control over the constraint associated index creation, see http://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes003.htm.
In your case the TABLESPACE storage clause.
If you want to let Oracle use the default tablespace you can remove the USING INDEX clause entirely leaving ENABLE.
Although in a CREATE TABLE a primary key constraint associated index is automatically enabled (unless I missed something) so I can't see any point of keeping the ENABLE.
Related
I have a SQL block to create a primary key constraint and in that SQL statement I found a clause
storage initial
I couldn't understand what it do and what is the reason for putting it, can somebody tell me what that storage initial means when it comes to creating a constraint or index in oracle.
ALTER TABLE table_name ADD CONSTRAINT constraint_name
....
....
STORAGE INITIAL
As explained in the Oracle documentation, if the constraint requires an index, this clause allows defining how it should physically be stored (initial extent size...).
I came across two code snippets :
one...
ALTER TABLE table_name
DROP CONSTRAINT constraint_name;
DROP INDEX index_name;
alter TABLE table_name ADD CONSTRAINT constraint_name PRIMARY KEY (column, column)
USING INDEX TABLESPACE tablespace_name;
Two ...
CREATE INDEX index_name ON table_name (column_name)
TABLESPACE tablespace_name;
Now I can understand the statements that are not in bold but the statements in bold are quite difficult to understand. Why are we using tablespaces, especially in this context? What is the meaning of these two statements? Can someone give me a detailed answer with examples?
Thank you!
A tablespace is a logical storage unit. Actual OS storage is defined in datafiles, and datafiles are linked to a tablespace. This means that we can deploy database objects on different servers, different OS even, without needing to know the underlying directory structure.
As for index tablespaces, indexes are physical objects and need to be stored somewhere. These days it is not as common to distinguish between Index tablespaces and table tablespaces, because modern servers are raided, striped, etc so nobody need worry about disk heads.
In fact, Oracle's built-in tablespace management is so good that we can largely forget about tablespace planning altogether. There is still a case for having separate tablespaces for e.g. read-only data, transportable tablespaces, partitioning, etc.
I have sql Upgrade script which has many sql statements(DDL,DML). When i ran this upgrade script in SQL developer, it runs successufully.I also provide in my script at the bottom commit. I can see all the changes in the database after running this upgrade script except the unique index constraints. When i insert few duplicate records it says unique constraint violated. It means the table has unique constraints. But i dont know why i cant view this constraints in oracle sql developer. The other DDL changes made i can view.I dont know is there any settings to view it in oracle sql developer.
CREATE UNIQUE INDEX "RATOR_MONITORING"."CAPTURING_UK1" ON "RATOR_MONITORING"."CAPTURING" ("DB_TABLE");
CREATE UNIQUE INDEX "RATOR_MONITORING_CONFIGURATION"."BRAND_UK1" ON "RATOR_MONITORING_CONFIGURATION"."BRAND" ("NAME");
CREATE UNIQUE INDEX "RATOR_MONITORING_CONFIGURATION"."BRAND_BUSINESS_PROCESS_UK1" ON "RATOR_MONITORING_CONFIGURATION"."BRAND_BUSINESS_PROCESS" ("BRAND_ID", "BP_ID");
CREATE UNIQUE INDEX "RATOR_MONITORING_CONFIGURATION"."BRAND_ENGINE_UK1" ON "RATOR_MONITORING_CONFIGURATION"."BRAND_ENGINE" ("BRAND_ID", "ENGINE_ID");
As A Hocevar noted, if you create an index
create unique index test_ux on test(id);
you see it in the Indexes tab of the table properties (not in the Constraints tab).
Please note that COMMIT is not required here, it is done implicitely in each DDL statement. More usual source of problems are stale metadata in SQL Developer, i.e. missing REFRESH (ctrl R on user or table node).
If you want to define the constraint, add following statement, that will reuse the index defined previously
alter table test add constraint test_unique unique(id) using index test_ux;
See further discussion about the option in Documentation
I am assuming you are trying to look for index on a table in the correct tab in sql developer. If you are not able to see the index there, one reason could be that your user (the one with which you are logged in) doesn't have proper rights to see the Index.
If you not obtain any error, the solution is very simple and tedious. SQL Developer doesn't refresh his fetched structures. Kindly push Refresh blue icon (or use Ctrl-R) in Connections view or disconnect and connect again (or restart SQL Developer) to see your changes in structures.
We have a requirement to delete rows in the order of millions from multiple tables as a batch job (note that we are not deleting all the rows, we are deleting based on a timestamp stored in an indexed column). Obviously a normal DELETE takes forever (because of logging, referential constraint checking etc.). I know in the LUW world, we have ALTER TABLE NOT LOGGED INITIALLY but I can't seem to find the an equivalent SQL statement for DB2 v8 z/OS. Any one has any ideas on how to do this really fast? Also, any ideas on how to avoid the referential checks when deleting the rows? Please let me know.
In the past I have solved this kind of problem by exporting the data and re-loading it with a replace style command. For example:
EXPORT to myfile.ixf OF ixf
SELECT *
FROM my_table
WHERE last_modified < CURRENT TIMESTAMP - 30 DAYS;
Then you can LOAD it back in, replacing the old stuff.
LOAD FROM myfile.ixf OF ixf
REPLACE INTO my_table
NONRECOVERABLE INDEXING MODE INCREMENTAL;
I'm not sure whether this will be faster or not for you (probably it depends on whether you're deleting more than you're keeping).
Do the foreign keys already have indexes as well?
How do you have your delete action set? CASCADE, NULL, NO ACTION
Use SET INTEGRITY to temporarily disable constraints on the batch process.
http://www.ibm.com/developerworks/data/library/techarticle/dm-0401melnyk/index.html
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r
We modified the tablespace so the lock would occur at the tablespace level instead of at the page level. Once we changed that DB2 only required one lock to do the DELETE and we didn't have any issues with locking. As for the logging, we just asked the customer to be aware of the amount of logging required (as there did not seem to be a solution to get around the logging issue). As for the constraints, we just dropped and recreated them after the delete.
Thanks all for your help.
I would like to rename an index. I've looked at the alter table documentation, but I can't figure out the syntax to simply rename an index. When doing it through the MySQL GUI, it drops the index, and creates a new one. While this works, I would like to avoid rebuilding the entire index just to change the name of an index.
[ADDITIONAL INFO]
In the alter table documentation it states
Alterations that modify only table
metadata and not table data can be
made immediately by altering the
table's .frm file and not touching
table contents. The following changes
are fast alterations that can be made
this way:
* Renaming a column or index.
However, when I tried to rename the index by editing the .frm file (on a test database) and restarting the server, it now states "Could not fetch columns" in the UI when trying to list the columns, and when trying to run a query, it returns the error "Unknown table engine ''". The .frm file has a lot of binary content. Is there a good tool for editing the binary info.
I answered this question in 2009. At that time there was no syntax in MySQL to rename an index.
Since then, MySQL 5.7 introduced an ALTER TABLE RENAME INDEX syntax.
http://dev.mysql.com/doc/refman/5.7/en/alter-table.html says in part:
RENAME INDEX old_index_name TO new_index_name renames an index. This is a MySQL extension to standard SQL. The content of the table remains unchanged. old_index_name must be the name of an existing index in the table that is not dropped by the same ALTER TABLE statement. new_index_name is the new index name, which cannot duplicate the name of an index in the resulting table after changes have been applied. Neither index name can be PRIMARY.
Earlier versions of MySQL, e.g. 5.6 and earlier, support no syntax in ALTER TABLE to rename an index (or key, which is a synonym).
The only solution was to ALTER TABLE DROP KEY oldkeyname, ADD KEY newkeyname (...).
There is no ALTER INDEX command in MySQL. You can only DROP INDEX and then CREATE INDEX with the new name.
Regarding your update above: perhaps the documentation isn't precise enough. Regardless, there's no SQL syntax to rename an index.
An index is a data structure that can be rebuilt from the data (in fact it's recommended to rebuild indexes periodically with OPTIMIZE TABLE). It takes some time, but it's a commonplace operation. Indexes data structures are separate from table data, so adding or dropping an index shouldn't need to touch the table data, as the documentation says.
Regarding the .frm file, MySQL does not support editing the .frm file. I wouldn't do it for any reason. You are 100% guaranteed to corrupt your table and make it unusable.
For MySQL 5.7:
ALTER TABLE tbl_name RENAME INDEX old_index_name TO new_index_name
For MySQL older versions:
ALTER TABLE tbl_name DROP INDEX old_index_name, ADD INDEX new_index_name (...)
See http://dev.mysql.com/doc/refman/5.7/en/alter-table.html
This question was asked ages ago, and was last updated over half a year ago.
Still I feel the need to add this tip:
If the indexed column is used elsewhere as a foreign key, you may encounter an error related to that. Doing this may help:
SET FOREIGN_KEY_CHECKS = 0;
ALTER TABLE tbl DROP INDEX index_name;
ALTER TABLE tbl ADD INDEX new_index_name (indexed_column);
SET FOREIGN_KEY_CHECKS = 1;
Hope someone finds this useful.