After dropping the table, found that the index created on the columns of the dropped table is gone. I just want to know what happens after that. Could someone please explain?
What all are the others getting dropped along with table drop?
In Oracle when dropping a table
all table indexes and domain indexes are dropped
any triggers defined on the table are dropped
if table is partitioned, any corresponding local index partitions are dropped
if the table is a base table for a view or if it is referenced in a stored procedure, function, or package, then these dependent objects are invalidated but not dropped
In Postgres
DROP TABLE always removes -
1. any indexes
2. rules
3. triggers
4. constraints
that exist for the target table.
MySQL also drops table indexes when tables are dropped.
For more info, see Does dropping a table in MySQL also drop the indexes?
By default, MS Sql Server also drops indexes when a table is dropped.
(Observed in version 13.0.4206.0.)
Related
In postgres when I drop a table it is dropping all views that depend upon it. Is there a way to persist the views so that they dont get dropped
Note: the table will be regenerated on daily basis with new data.
From PostgreSQL documentation
DROP TABLE always removes any indexes, rules, triggers, and constraints that exist for the target table. However, to drop a table that is referenced by a view or a foreign-key constraint of another table, CASCADE must be specified. (CASCADE will remove a dependent view entirely, but in the foreign-key case it will only remove the foreign-key constraint, not the other table entirely.)
Try TRUNCATE TABLE / CREATE TABLE IF NOT EXISTS instead of DROP.
I am trying to drop a varchar(100) column of a 150 GB table (4.6 billion records). All the data in this column is null. I have 30GB more space in the database.
When I attempt to drop the column, it says "no more room in database XY". Why does such an action needs so much space?
The ALTER TABLE statement needs a temporary storage for the altered version before overwriting the original table. I guess the the table that you are trying to alter occupies at least 1/3 of your total storage size
This could happen for a variety of reasons. It's possible that one of the AMP's in your database are full, this would cause that error even with a minor table alteration.
try running the following SQL to check space
select VProc, CurrentPerm, MaxPerm
from dbc.DiskSpace
where DatabaseName='XY';
also, you should check to see what column your primary index is on in this very large table. if the table is not skewed properly, you could also run into space issues when trying to alter a table or by running a query against it.
For additional suggestions I found a decent article on the kind of things you may want to investigate when the "no more room in database" error occurs - Teradata SQL Tutorial. Some of the suggestions include:
dropping any intermediary work or "sandbox" tables
implementing single value or multi-value compression.
dropping unwanted/unnecessary secondary indexes
removing data in dbc tables like accesslog or dbql tables
remove and archive old tables that are no longer used.
If I rename SQLite Tables/Columns/Rows after indices have been created, will the old indices still be functional?
Thanks!
If you're using ALTER TABLE with RENAME TO to rename a table, then as described on this page (from the sqlite docs) the indices will still work:
The ALTER TABLE command in SQLite allows the user to rename a table [...] If the table being renamed has triggers or indices, then these remain attached to the table after it has been renamed.
But note there's no renaming of columns allowed. This is one of the SQL features not implemented by sqlite:
Only the RENAME TABLE and ADD COLUMN variants of the ALTER TABLE command are supported. Other kinds of ALTER TABLE operations such as DROP COLUMN, ALTER COLUMN, ADD CONSTRAINT, and so forth are omitted.
Rows don't have names (except in the sense of having a PK) so there's not really a way of renaming them.
I highly recommend using Rails ActiveRecord migrations to maintain your database. This can be done outside of Rails. So you app doesn't need to be a Rails app to use rake tasks
See here for an excellent blog on how to do this http://exposinggotchas.blogspot.com/2011/02/activerecord-migrations-without-rails.html
Yes, the old indices will still be functional.
Be aware, that sqlite doesn't care about the names for the indexes. Initially when an index is created usually they are named after the table and field, so when you rename the table, the indexes will still have the name of the old table in it. This can cause problems, when you for example:
dump the table
rename the old table:
sqlite3 "$DB" "PRAGMA busy_timeout=20000; ALTER TABLE '$TABLE' RENAME TO '$TABLE"_backup"'"
reimport the dumped table
This will cause an error, that the indexes already exist.
Solution: Rename the indexes too, or delete them in the renamed table before you reimport the original (see this answer).
I have a staging table (stage_enrolments) and a production table (enrolments). The staging table isn't partitioned, the production table is. I'm trying to use the ALTER TABLE SWITCH statement to transfer the records in the staging table to production.
ALTER TABLE dbo.stage_enrolments
SWITCH TO dbo.enrolments PARTITION #partition_num;
However, when I execute this statement I get the following error:
ALTER TABLE SWITCH statement failed. Target table 'Academic.dbo.enrolments' is referenced by 1 indexed view(s), but source table 'Academic.dbo.stage_enrolments' is only referenced by 0 matching indexed view(s)
I have the same indexed view defined on dbo.stage_enrolments as I do on dbo.enrolments - although the view on enrolments is partitioned. I've tried recreating the views and their indexes checking that all options are the same but I get the same result. If I remove the index from the dbo.enrolments view then it works fine.
I have it working on another set of tables that have indexed views so I'm not sure why it isn't working for these. Does anyone have an idea as to why this may be occurring? What else should I check?
The problem has now been sorted. I've recreated the indexed view once again and it is now working. I haven't actually changed anything though other than the name of the index so I'm not sure what the problem was.
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.