looking for examples on doing a large table cleanup where my attribute value selected has an attribute_value of Null. I would like to
maybe do it in Batches where I deleted say 20,000 in 5 iterations then exit.
Attribute = 'csx' and attribute_value is null
Thanks.
CREATE TABLE [dbo].[Quality_Attribute](
[Quality_ID] [int] NOT NULL,
[Attribute] [nvarchar](100) NOT NULL,
[Attribute_Value] [nvarchar](100) NULL,
[Attribute_DateTime] [datetime] NULL,
CONSTRAINT [PK_Quality_Attribute] PRIMARY KEY CLUSTERED
(
[Quality_ID] ASC,
[Attribute] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
Is this a repeat of this question: https://www.sqlservercentral.com/forums/topic/large-table-cleanup-using-delete
Why start up a new conversation for something where you accepted an answer?
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
November 28, 2021 at 4:29 pm
Thanks was trying to find it...
Was there a way to log the numbers of deletes as I go.
Thx.
November 28, 2021 at 5:00 pm
If you need to find previous posts - go to your profile and select 'Topics Started'. Review the previous thread - @JeffModen provided a similar template with additional options for reporting progress.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
November 28, 2021 at 5:04 pm
Thx.
November 28, 2021 at 11:34 pm
As a bit of a sidebar, one does have to wonder what the word "efficient" in the post title actually means because, IMHO, you selected to go with the least "efficient" method in the other thread.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 29, 2021 at 12:54 am
Are you suggesting
Depending upon how much data you are saving, it may be faster/easier to select what you want to keep into a new table. Drop the PK, FK and indexes on the original table, rename the original table, and rename the new table to the old table's name, and then re-apply the constraints
November 29, 2021 at 1:54 am
That's almost exactly what I suggested in the other post. You ARE trying to delete 41% of the table. After doing that (deletes), you're going to have to rebuild all the indexes, anyway.
And, no. I wouldn't drop the clustered index even if it's a named constraint being used for a Primary Key. Dropping it will cause it to "rebuild" the old table as a "heap" and that can take a lot of time. Constraints can be renamed just as easily as a table and, the cool part is, it'll rename the underlying objects. For example, if you change the name of a PK constraint, it'll also change the name of the underlying index.
And, DELETEs are always fully logged. You could do almost all of this in a very high speed, minimally logged fashion if you can make a trip to the BULK LOGGED Recovery Model.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply