Your question, your audience. Choose who sees your identity—and your question—with question security.
Cannot drop table because it is being used for replication
SERVER 2008
WINDOWS SERVER 2008
I have a database that gets updated every night with new data that I import from an external server. This database is also replicated each hour to another database which is used by a website.
More detailed ... at 3am each morning I import the new data, drop the existing tables and INSERT INTO a new table, then create new indexes and constraints. From 3:30am - 6:30 pm, I publish these new tables each hour ... my website database is the subscriber.
Since I set up the replication, I get the error that I cannot drop the table because it is being used with replication. I am aware that I can rather delete the table contents (rather than drop the table) and insert the new data, but I prefer to drop the tables because it uses much less resources.
MY QUESTION: Is there a stored procedure or another method that will allow me to simply disable the replication, run my TSQL code that drops and recreates the tables, and then re-enable the replication ... or do I have to actually drop the replication, run my TSQL, then recreate the replication (using TSQL).
Any advice would be very appreciated!
Max
WINDOWS SERVER 2008
I have a database that gets updated every night with new data that I import from an external server. This database is also replicated each hour to another database which is used by a website.
More detailed ... at 3am each morning I import the new data, drop the existing tables and INSERT INTO a new table, then create new indexes and constraints. From 3:30am - 6:30 pm, I publish these new tables each hour ... my website database is the subscriber.
Since I set up the replication, I get the error that I cannot drop the table because it is being used with replication. I am aware that I can rather delete the table contents (rather than drop the table) and insert the new data, but I prefer to drop the tables because it uses much less resources.
MY QUESTION: Is there a stored procedure or another method that will allow me to simply disable the replication, run my TSQL code that drops and recreates the tables, and then re-enable the replication ... or do I have to actually drop the replication, run my TSQL, then recreate the replication (using TSQL).
Any advice would be very appreciated!
Max
Asked:
Who is Participating?
If the table is enabled for replication then unfortunately the answer is yes - you must drop replication first, modifi your table structure, and enable replication again.
I know is a pain however it's the only way it works.
I know is a pain however it's the only way it works.
@ iCOHAN,
Can you confirm ... In Mgmnt Studio, under the Replication tab I can see my publications. If I right click on a publication, I can choose Generate Scripts. On the window that opens I can either choose to create a script to "Disable/Drop Components" or "Enable/Create Components".
Is as simple as creating scripts to Disable/Drop the publisher components and run this before I drop the tables, then run the script to Enable/Create the components after I have dropped/updated the tables?
Btw, I used to DELETE and then INSERT but my database size was becoming to large, so that is why I changed it to DROP and SELECT INTO. At the same time I also changed the recovery model to simple to help keep the log files smaller ... Will the T-Logs grow larger using DELETE or TRUNCATE as opposed to DROP, or were my log files getting so large mainly because I was using a FULL recovery model before?
Max
Can you confirm ... In Mgmnt Studio, under the Replication tab I can see my publications. If I right click on a publication, I can choose Generate Scripts. On the window that opens I can either choose to create a script to "Disable/Drop Components" or "Enable/Create Components".
Is as simple as creating scripts to Disable/Drop the publisher components and run this before I drop the tables, then run the script to Enable/Create the components after I have dropped/updated the tables?
Btw, I used to DELETE and then INSERT but my database size was becoming to large, so that is why I changed it to DROP and SELECT INTO. At the same time I also changed the recovery model to simple to help keep the log files smaller ... Will the T-Logs grow larger using DELETE or TRUNCATE as opposed to DROP, or were my log files getting so large mainly because I was using a FULL recovery model before?
Max
TRUNCATE TABLE is different than DELETE.
http://www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/A_2667-The-Difference-Between-Truncation-and-Deletion.html
If the only reason you changed is due to table size and T-Log growth, see information on TRUNCATE. I use it to clear three tables with about 6-10 million rows before running a process that was written to do DELETE and as such run out of space before completion. Running TRUNCATE before, it runs without needing incremental log space.
http://www.experts-exchange.com/Microsoft/Development/MS-SQL-Server/A_2667-The-Difference-Between-Truncation-and-Deletion.html
If the only reason you changed is due to table size and T-Log growth, see information on TRUNCATE. I use it to clear three tables with about 6-10 million rows before running a process that was written to do DELETE and as such run out of space before completion. Running TRUNCATE before, it runs without needing incremental log space.
"mwvisa1" is right with truncate and use that if you can because all DELETE/INSERT rows wil go thrugh DBs t-logs via replication.
http://msdn.microsoft.com/en-us/library/ms177570.aspx
"SQL Server 2008 R2 Other Versions SQL Server "Denali" SQL Server 2008 SQL Server 2005
Removes all rows from a table without logging the individual row deletions. TRUNCATE TABLE is similar to the DELETE statement with no WHERE clause; however, TRUNCATE TABLE is faster and uses fewer system and transaction log resources."
http://msdn.microsoft.com/en-us/library/ms177570.aspx
"SQL Server 2008 R2 Other Versions SQL Server "Denali" SQL Server 2008 SQL Server 2005
Removes all rows from a table without logging the individual row deletions. TRUNCATE TABLE is similar to the DELETE statement with no WHERE clause; however, TRUNCATE TABLE is faster and uses fewer system and transaction log resources."
Yes this all about controlling the log file size. I don't care if there are any log files in this database, because it gets re-created each night and is read only ... the data already exists somewhere.
I have changed everything to TRUNCATE TABLE and INSERT INTO, but my log still keeps growing approx 2 GB each time I run the T-SQL job. I am dealing with mid-hundred thousand records in the half of the tables ... much less in the other half.
How can I control the file size? I thought that if I used simple recovery and ran a FULL backup, that would truncate the log file ... am I mistaken? When I was dropping the tables (before replication), my dbase size stayed around 7-10 GB ... now after running the job a couple times, it is already 33 GB.
Max
I have changed everything to TRUNCATE TABLE and INSERT INTO, but my log still keeps growing approx 2 GB each time I run the T-SQL job. I am dealing with mid-hundred thousand records in the half of the tables ... much less in the other half.
How can I control the file size? I thought that if I used simple recovery and ran a FULL backup, that would truncate the log file ... am I mistaken? When I was dropping the tables (before replication), my dbase size stayed around 7-10 GB ... now after running the job a couple times, it is already 33 GB.
Max
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
All Courses
From novice to tech pro — start learning today.
