Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 5178
  • Last Modified:

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
0
MaxwellTurner
Asked:
MaxwellTurner
  • 3
  • 2
  • 2
1 Solution
 
Kevin CrossChief Technology OfficerCommented:
If you are just worried about resources, you can TRUNCATE TABLE and DROP the indices.
0
 
lcohanDatabase AnalystCommented:
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.
0
 
MaxwellTurnerAuthor Commented:
@ 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
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
Kevin CrossChief Technology OfficerCommented:
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.
0
 
lcohanDatabase AnalystCommented:
"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."
0
 
MaxwellTurnerAuthor Commented:
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
0
 
MaxwellTurnerAuthor Commented:
UPDATE:  I was looking at the size of another dbase by mistake ... it seems I am holding steady at 20 GB after running the job a couple more times.  I can live with that!

Thanks for all the helpful info guys.

Max
0
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.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now