b**a
发帖数: 1118 | 1 Now we can only delete them in 1 hour. How to make it in 30 mins?
Thanks,
Ming |
B*****g
发帖数: 34098 | 2 what database?
which version?
table partitioned?
any audit/archive is using?
【在 b**a 的大作中提到】
: Now we can only delete them in 1 hour. How to make it in 30 mins?
: Thanks,
: Ming
|
b**a
发帖数: 1118 | 3 发信人: Beijing (中国万岁，北京加油), 信区: Database
标 题: Re: How to delete 40 millions records in a 400 millions indexe
发信站: BBS 未名空间站 (Tue Jan 24 17:58:08 2012, 美东)
what database? sql server 2008
which version?
table partitioned? no
any audit/archive is using? no idea...
【 在 buaa (ming) 的大作中提到: 】 |
b**a
发帖数: 1118 | 4 I am using sth like this now:
DECLARE @count2 int
SET @count2 = 10000
WHILE @count2 >= 10000
BEGIN
DELETE temp from ( SELECT TOP 10000 * FROM Transactions WITH(NOLOCK)
WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate)
temp OPTION (MAXDOP 1)
SELECT @count2 = @@ROWCOUNT
END
and i really need it to run faster...
【在 b**a 的大作中提到】
: 发信人: Beijing (中国万岁，北京加油), 信区: Database
: 标 题: Re: How to delete 40 millions records in a 400 millions indexe
: 发信站: BBS 未名空间站 (Tue Jan 24 17:58:08 2012, 美东)
: what database? sql server 2008
: which version?
: table partitioned? no
: any audit/archive is using? no idea...
: 【 在 buaa (ming) 的大作中提到: 】
|
i****a
发帖数: 36252 | 5 Do a larger batch than 10k should help. And just do delete without the sub
select.m
Are your lookup parameters indexed?
And what's the purpose of (MAXDOP 1)?
)
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: I am using sth like this now:
: DECLARE @count2 int
: SET @count2 = 10000
: WHILE @count2 >= 10000
: BEGIN
: DELETE temp from ( SELECT TOP 10000 * FROM Transactions WITH(NOLOCK)
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate)
: temp OPTION (MAXDOP 1)
: SELECT @count2 = @@ROWCOUNT
: END
|
c*****d
发帖数: 6045 | 6 这个是dba interview最常见的问题吧
【在 b**a 的大作中提到】
: Now we can only delete them in 1 hour. How to make it in 30 mins?
: Thanks,
: Ming
|
b**a
发帖数: 1118 | 7 The where clause is using the field that is indexed
【在 i****a 的大作中提到】
: Do a larger batch than 10k should help. And just do delete without the sub
: select.m
: Are your lookup parameters indexed?
: And what's the purpose of (MAXDOP 1)?
:
: )
: [发表自未名空间手机版 - m.mitbbs.com]
|
i****a
发帖数: 36252 | 8 Can you do delete without the sub
select. Put the where clause in to the delete statement.
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: The where clause is using the field that is indexed
|
b**a
发帖数: 1118 | 9 I actually get the idea from the following link:
http://sqlblogcasts.com/blogs/simons/archive/2009/05/22/DELETE-
A view is supposed to be faster but i did not figure out the way to create a
view in begin and end block so I gave up.
【在 i****a 的大作中提到】
: Can you do delete without the sub
: select. Put the where clause in to the delete statement.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
i****a
发帖数: 36252 | 10 Try with just delete top 100000 from tbl where ....
a
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: I actually get the idea from the following link:
: http://sqlblogcasts.com/blogs/simons/archive/2009/05/22/DELETE-
: A view is supposed to be faster but i did not figure out the way to create a
: view in begin and end block so I gave up.
|
|
|
B*****g
发帖数: 34098 | 11 同时run 10个会不会快？
create
【在 i****a 的大作中提到】
: Try with just delete top 100000 from tbl where ....
:
: a
: [发表自未名空间手机版 - m.mitbbs.com]
|
b**a
发帖数: 1118 | 12 How?
Thanks.
【在 B*****g 的大作中提到】
: 同时run 10个会不会快？
:
: create
|
c*****d
发帖数: 6045 | 13 同时run 10个，每个delete 4 millions record?
这个方法性能更慢
【在 B*****g 的大作中提到】
: 同时run 10个会不会快？
:
: create
|
c*****d
发帖数: 6045 | 14 没看太明白
是不是要删除transacitons表中某段时间的记录
如果要删除的记录超过10000条，10001条以后的就不删除了？
)
【在 b**a 的大作中提到】
: I am using sth like this now:
: DECLARE @count2 int
: SET @count2 = 10000
: WHILE @count2 >= 10000
: BEGIN
: DELETE temp from ( SELECT TOP 10000 * FROM Transactions WITH(NOLOCK)
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate)
: temp OPTION (MAXDOP 1)
: SELECT @count2 = @@ROWCOUNT
: END
|
b**a
发帖数: 1118 | 15 No. This is to delete 10000 each batch and keep deleting untill every
records that qualified get deleted.
【在 c*****d 的大作中提到】
: 没看太明白
: 是不是要删除transacitons表中某段时间的记录
: 如果要删除的记录超过10000条，10001条以后的就不删除了？
:
: )
|
i****a
发帖数: 36252 | 16 Then you have a bug in the while condition.
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: No. This is to delete 10000 each batch and keep deleting untill every
: records that qualified get deleted.
|
b**a
发帖数: 1118 | 17 what is it?
Thanks.
【在 i****a 的大作中提到】
: Then you have a bug in the while condition.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
i****a
发帖数: 36252 | 18 Never mind, its fine.
Just try different coding and batch sizes.
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: what is it?
: Thanks.
|
B*****g
发帖数: 34098 | 19 假设每个删除都删除不同的range呢？
【在 c*****d 的大作中提到】
: 同时run 10个，每个delete 4 millions record?
: 这个方法性能更慢
|
y****w
发帖数: 3747 | 20 10000的批次太小，换成10w或100w重新跑。问下你们的dba，保证log空间足够。
WITH(NOLOCK
)
@EndDate)
【在 b**a 的大作中提到】
: I am using sth like this now:
: DECLARE @count2 int
: SET @count2 = 10000
: WHILE @count2 >= 10000
: BEGIN
: DELETE temp from ( SELECT TOP 10000 * FROM Transactions WITH(NOLOCK)
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate)
: temp OPTION (MAXDOP 1)
: SELECT @count2 = @@ROWCOUNT
: END
|
|
|
y****w
发帖数: 3747 | 21 sql server的锁和oracle的很不一样。
【在 B*****g 的大作中提到】
: 同时run 10个会不会快？
:
: create
|
B*****g
发帖数: 34098 | 22 2008不是改善了吗？另外如果有partition可行吗？
【在 y****w 的大作中提到】
: sql server的锁和oracle的很不一样。
|
y****w
发帖数: 3747 | 23 并发delete总是要受影响的吧。各个并发之间必须有严格的界限，不然以set的无序特
性，跑跑就锁死了，或操作旧数据了。
lz这个没table partition，用partition/order by硬排序出来或许行，用rank避免最
后那组值的随机性.
没注意sql 2008支持不支持类似currently committed语义。
【在 B*****g 的大作中提到】
: 2008不是改善了吗？另外如果有partition可行吗？
|
j*****n
发帖数: 1781 | 24 partitioning will definitely improve the performance.
specially if the partition(s) hold only the records that will be deleted,
then the delete action will take no time via dropping the partition(s).
【在 B*****g 的大作中提到】
: 2008不是改善了吗？另外如果有partition可行吗？
|
y****w
发帖数: 3747 | 25 sql大拿说说sql server 2008/denali的锁机制，在并发读写方面的改进？
【在 j*****n 的大作中提到】
: partitioning will definitely improve the performance.
: specially if the partition(s) hold only the records that will be deleted,
: then the delete action will take no time via dropping the partition(s).
|
c*****d
发帖数: 6045 | 26 除非你知道每个range在哪个block上
【在 B*****g 的大作中提到】
: 假设每个删除都删除不同的range呢？
|
i****a
发帖数: 36252 | 27 I think mainly the time is spend on i/o. But can't tell without a perfmon
trace.
[发表自未名空间手机版 - m.mitbbs.com]
【在 B*****g 的大作中提到】
: 假设每个删除都删除不同的range呢？
|
B*****g
发帖数: 34098 | 28 他那个有时间range，可以人为地分成几个range，sql其实是不同的，数据相互间就可
以独立
【在 y****w 的大作中提到】
: 并发delete总是要受影响的吧。各个并发之间必须有严格的界限，不然以set的无序特
: 性，跑跑就锁死了，或操作旧数据了。
: lz这个没table partition，用partition/order by硬排序出来或许行，用rank避免最
: 后那组值的随机性.
: 没注意sql 2008支持不支持类似currently committed语义。
|
B*****g
发帖数: 34098 | 29 server上很多CPU的
【在 i****a 的大作中提到】
: I think mainly the time is spend on i/o. But can't tell without a perfmon
: trace.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
B*****g
发帖数: 34098 | 30 zkss
【在 c*****d 的大作中提到】
: 除非你知道每个range在哪个block上
|
|
|
i****a
发帖数: 36252 | 31 Not cpu. I'm refering to disk i/o.
Without optimizing query, most likely the bottle neck is at i/o. Running
mulitple instances of the query wouldn't help if they all wait for the disk.
[发表自未名空间手机版 - m.mitbbs.com]
【在 B*****g 的大作中提到】
: server上很多CPU的
|
B*****g
发帖数: 34098 | 32 这个table显然是需要partition，哈哈
【在 j*****n 的大作中提到】
: partitioning will definitely improve the performance.
: specially if the partition(s) hold only the records that will be deleted,
: then the delete action will take no time via dropping the partition(s).
|
B*****g
发帖数: 34098 | 33 多几个SQL就把Disk搞死了，呵呵
disk.
【在 i****a 的大作中提到】
: Not cpu. I'm refering to disk i/o.
: Without optimizing query, most likely the bottle neck is at i/o. Running
: mulitple instances of the query wouldn't help if they all wait for the disk.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
y****w
发帖数: 3747 | 34 lz这个瓶颈我认为是因为batch size太小带来的循环冗余开销。原先那个sql跑起来估计机器的
cpu/io都不能真正忙起来，但换个角度过来说，总体cpu/io比一次删除的要多了n多倍。
他那个表有400M rows，是个大型库，机器应该差不到哪里去，日志配置应该也不会太
小气。删10M记录应该比做1000次每次10000条要快的多，lz的要求也就是提高一半，改
下batch size应该够用了。lz应该试试然后贴个结果上来。
Running
the
disk.
【在 i****a 的大作中提到】
: Not cpu. I'm refering to disk i/o.
: Without optimizing query, most likely the bottle neck is at i/o. Running
: mulitple instances of the query wouldn't help if they all wait for the disk.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
B*****g
发帖数: 34098 | 35 这个需要测试，据俺测试oracle9i，一般来说1w和10w差不多。另外lz的code为啥要
hardcode 10000很多次？
估计机器的
倍。
【在 y****w 的大作中提到】
: lz这个瓶颈我认为是因为batch size太小带来的循环冗余开销。原先那个sql跑起来估计机器的
: cpu/io都不能真正忙起来，但换个角度过来说，总体cpu/io比一次删除的要多了n多倍。
: 他那个表有400M rows，是个大型库，机器应该差不到哪里去，日志配置应该也不会太
: 小气。删10M记录应该比做1000次每次10000条要快的多，lz的要求也就是提高一半，改
: 下batch size应该够用了。lz应该试试然后贴个结果上来。
:
: Running
: the
: disk.
|
y****w
发帖数: 3747 | 36 随手的脚本写法，保证能删光，又不想费事儿去搞到精确的批次，要不加个@@rowcount
=0跳出来也就行了。
【在 B*****g 的大作中提到】
: 这个需要测试，据俺测试oracle9i，一般来说1w和10w差不多。另外lz的code为啥要
: hardcode 10000很多次？
:
: 估计机器的
: 倍。
|
y****w
发帖数: 3747 | 37 这么多的行删除，需要的行锁太多; 如果锁升级的话影响怎样,页锁/表锁会破坏本来sql语句之间的
隔离？。 sql server没那么熟，不好说。
【在 B*****g 的大作中提到】
: 他那个有时间range，可以人为地分成几个range，sql其实是不同的，数据相互间就可
: 以独立
|
B*****g
发帖数: 34098 | 38 等待大牛中
sql语句之间的
【在 y****w 的大作中提到】
: 这么多的行删除，需要的行锁太多; 如果锁升级的话影响怎样,页锁/表锁会破坏本来sql语句之间的
: 隔离？。 sql server没那么熟，不好说。
|
a9
发帖数: 21638 | 39 先把不重要的索引删掉。
【在 b**a 的大作中提到】
: Now we can only delete them in 1 hour. How to make it in 30 mins?
: Thanks,
: Ming
|
c*****d
发帖数: 6045 | 40 假如你run 10个batch，这些batch都在修改同一个db block or db page
【在 B*****g 的大作中提到】
: zkss
|
|
|
c*****d
发帖数: 6045 | 41 时间字段上的range －－－逻辑
data blocks range －－－物理
一般情况下是不会一一对应的
很可能一个block上有今天的数据，也有100年以前的数据
【在 B*****g 的大作中提到】
: 他那个有时间range，可以人为地分成几个range，sql其实是不同的，数据相互间就可
: 以独立
|
y****w
发帖数: 3747 | 42 数据量小时行锁就行了。lz这个行锁肯定不够用，要上页锁甚至表锁。看dbms具体实现lock wait
的时间可能差很多。 逻辑上独立这个前提就有可能导致实现上的优化。所以我说还是得真懂sql
server的来说说sql server目前以及可预期版本的实现。
再说今天很对的东西，过几年也许就变成错的了。
【在 c*****d 的大作中提到】
: 时间字段上的range －－－逻辑
: data blocks range －－－物理
: 一般情况下是不会一一对应的
: 很可能一个block上有今天的数据，也有100年以前的数据
|
B*****g
发帖数: 34098 | 43 同一时间在一起的可能性很大。LZ每次就锁1w个，delete01也许会lock delete02、03
，但总不会把02-10（假设开10个）都lock住吧。当然，对SQL server的lock不是很精
通，期待大牛详解SQL server Lock。另外如果SQL搞不定，可以考虑hibernate。
【在 c*****d 的大作中提到】
: 时间字段上的range －－－逻辑
: data blocks range －－－物理
: 一般情况下是不会一一对应的
: 很可能一个block上有今天的数据，也有100年以前的数据
|
c*****d
发帖数: 6045 | 44 “同一时间在一起的可能性很大”，未必，看应用
OLTP一个block上什么时间的数据都会有
03
【在 B*****g 的大作中提到】
: 同一时间在一起的可能性很大。LZ每次就锁1w个，delete01也许会lock delete02、03
: ，但总不会把02-10（假设开10个）都lock住吧。当然，对SQL server的lock不是很精
: 通，期待大牛详解SQL server Lock。另外如果SQL搞不定，可以考虑hibernate。
|
c*****d
发帖数: 6045 | 45 我没搞清楚lz是必须用sql delete的方法来删除
还是可以用其他方法来实现？ |
B*****g
发帖数: 34098 | 46 据说hibernate比SQL快
【在 c*****d 的大作中提到】
: 我没搞清楚lz是必须用sql delete的方法来删除
: 还是可以用其他方法来实现？
|
y****w
发帖数: 3747 | 47 这sql得写多烂？
【在 B*****g 的大作中提到】
: 据说hibernate比SQL快
|
b**a
发帖数: 1118 | 48 yes we have to do it in sql.
【在 c*****d 的大作中提到】
: 我没搞清楚lz是必须用sql delete的方法来删除
: 还是可以用其他方法来实现？
|
y****w
发帖数: 3747 | 49 have you tried bigger batch size? start with 1M.
【在 b**a 的大作中提到】
: yes we have to do it in sql.
|
b**a
发帖数: 1118 | 50 Log drive does not have that big space...
Thanks.
Ming
【在 y****w 的大作中提到】
: have you tried bigger batch size? start with 1M.
|
|
|
j*******7
发帖数: 6300 | 51 那个Delete语句可以这么写：
DELETE TOP(10000) FROM Transactions
WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate
Not sure if it's faster. The "select *" is bad in my eyes. |
b**a
发帖数: 1118 | 52 http://sqlblogcasts.com/blogs/simons/archive/2009/05/22/DELETE-
According to that link, that is faster actually than delete directly...
【在 j*******7 的大作中提到】
: 那个Delete语句可以这么写：
: DELETE TOP(10000) FROM Transactions
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate
: Not sure if it's faster. The "select *" is bad in my eyes.
|
j*******7
发帖数: 6300 | 53 Thank you. An old dog can still learn a new trick.
【在 b**a 的大作中提到】
: http://sqlblogcasts.com/blogs/simons/archive/2009/05/22/DELETE-
: According to that link, that is faster actually than delete directly...
|
y****w
发帖数: 3747 | 54 应该测试下，网上错的东西太多了，昨天对的今天也许就错了。这两种应该几乎没什么
差别才对，假如sql optimizer没干傻事的话。
【在 j*******7 的大作中提到】
: 那个Delete语句可以这么写：
: DELETE TOP(10000) FROM Transactions
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate
: Not sure if it's faster. The "select *" is bad in my eyes.
|
B*****g
发帖数: 34098 | 55 顶，tuning就是调试
【在 y****w 的大作中提到】
: 应该测试下，网上错的东西太多了，昨天对的今天也许就错了。这两种应该几乎没什么
: 差别才对，假如sql optimizer没干傻事的话。
|
t****3
发帖数: 2337 | |
b**a
发帖数: 1118 | 57 This is a variation from this article. Sounds very reasonable so I did not
do test.
Plus i do not have enough space and data in our dev platform to test so...
I am not a sql guy...
【在 y****w 的大作中提到】
: 应该测试下，网上错的东西太多了，昨天对的今天也许就错了。这两种应该几乎没什么
: 差别才对，假如sql optimizer没干傻事的话。
|
B*****g
发帖数: 34098 | 58 加入CINAOUG，你也可以成为sql guy
【在 b**a 的大作中提到】
: This is a variation from this article. Sounds very reasonable so I did not
: do test.
: Plus i do not have enough space and data in our dev platform to test so...
: I am not a sql guy...
|
g***l
发帖数: 18555 | 59 建一个一模一样的TABLE名字是TABLE_TEMP，注意PK, INDEXES， BULK INSERT你想留住
的RECORD INTO TABLE_TEMP，DROP OLD TABLE, RENAME TABLE_TEMP TO TABLE,
RECOMPILE TABLE |
b**a
发帖数: 1118 | 60 Now we can only delete them in 1 hour. How to make it in 30 mins?
Thanks,
Ming
Update:
Tried all i can except partitioned table. We cannot drop the index and rebuild it because other hourly sql job is going to insert a lot of records in the same table. Seemed no way to ensure it will finish in 30 mins so my solution is to add a waitfor delay 0.2 in every loop. In this way, the delete will finish much longer (2:30) but it will not affect any other jobs. |
|
|
B*****g
发帖数: 34098 | 61 what database?
which version?
table partitioned?
any audit/archive is using?
【在 b**a 的大作中提到】
: Now we can only delete them in 1 hour. How to make it in 30 mins?
: Thanks,
: Ming
: Update:
: Tried all i can except partitioned table. We cannot drop the index and rebuild it because other hourly sql job is going to insert a lot of records in the same table. Seemed no way to ensure it will finish in 30 mins so my solution is to add a waitfor delay 0.2 in every loop. In this way, the delete will finish much longer (2:30) but it will not affect any other jobs.
|
b**a
发帖数: 1118 | 62 发信人: Beijing (中国万岁，北京加油), 信区: Database
标 题: Re: How to delete 40 millions records in a 400 millions indexe
发信站: BBS 未名空间站 (Tue Jan 24 17:58:08 2012, 美东)
what database? sql server 2008
which version?
table partitioned? no
any audit/archive is using? no idea...
【 在 buaa (ming) 的大作中提到: 】 |
b**a
发帖数: 1118 | 63 I am using sth like this now:
DECLARE @count2 int
SET @count2 = 10000
WHILE @count2 >= 10000
BEGIN
DELETE temp from ( SELECT TOP 10000 * FROM Transactions WITH(NOLOCK)
WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate)
temp OPTION (MAXDOP 1)
SELECT @count2 = @@ROWCOUNT
END
and i really need it to run faster...
【在 b**a 的大作中提到】
: 发信人: Beijing (中国万岁，北京加油), 信区: Database
: 标 题: Re: How to delete 40 millions records in a 400 millions indexe
: 发信站: BBS 未名空间站 (Tue Jan 24 17:58:08 2012, 美东)
: what database? sql server 2008
: which version?
: table partitioned? no
: any audit/archive is using? no idea...
: 【 在 buaa (ming) 的大作中提到: 】
|
i****a
发帖数: 36252 | 64 Do a larger batch than 10k should help. And just do delete without the sub
select.m
Are your lookup parameters indexed?
And what's the purpose of (MAXDOP 1)?
)
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: I am using sth like this now:
: DECLARE @count2 int
: SET @count2 = 10000
: WHILE @count2 >= 10000
: BEGIN
: DELETE temp from ( SELECT TOP 10000 * FROM Transactions WITH(NOLOCK)
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate)
: temp OPTION (MAXDOP 1)
: SELECT @count2 = @@ROWCOUNT
: END
|
c*****d
发帖数: 6045 | 65 这个是dba interview最常见的问题吧
【在 b**a 的大作中提到】
: Now we can only delete them in 1 hour. How to make it in 30 mins?
: Thanks,
: Ming
: Update:
: Tried all i can except partitioned table. We cannot drop the index and rebuild it because other hourly sql job is going to insert a lot of records in the same table. Seemed no way to ensure it will finish in 30 mins so my solution is to add a waitfor delay 0.2 in every loop. In this way, the delete will finish much longer (2:30) but it will not affect any other jobs.
|
b**a
发帖数: 1118 | 66 The where clause is using the field that is indexed
【在 i****a 的大作中提到】
: Do a larger batch than 10k should help. And just do delete without the sub
: select.m
: Are your lookup parameters indexed?
: And what's the purpose of (MAXDOP 1)?
:
: )
: [发表自未名空间手机版 - m.mitbbs.com]
|
i****a
发帖数: 36252 | 67 Can you do delete without the sub
select. Put the where clause in to the delete statement.
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: The where clause is using the field that is indexed
|
b**a
发帖数: 1118 | 68 I actually get the idea from the following link:
http://sqlblogcasts.com/blogs/simons/archive/2009/05/22/DELETE-
A view is supposed to be faster but i did not figure out the way to create a
view in begin and end block so I gave up.
【在 i****a 的大作中提到】
: Can you do delete without the sub
: select. Put the where clause in to the delete statement.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
i****a
发帖数: 36252 | 69 Try with just delete top 100000 from tbl where ....
a
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: I actually get the idea from the following link:
: http://sqlblogcasts.com/blogs/simons/archive/2009/05/22/DELETE-
: A view is supposed to be faster but i did not figure out the way to create a
: view in begin and end block so I gave up.
|
B*****g
发帖数: 34098 | 70 同时run 10个会不会快？
create
【在 i****a 的大作中提到】
: Try with just delete top 100000 from tbl where ....
:
: a
: [发表自未名空间手机版 - m.mitbbs.com]
|
|
|
b**a
发帖数: 1118 | 71 How?
Thanks.
【在 B*****g 的大作中提到】
: 同时run 10个会不会快？
:
: create
|
c*****d
发帖数: 6045 | 72 同时run 10个，每个delete 4 millions record?
这个方法性能更慢
【在 B*****g 的大作中提到】
: 同时run 10个会不会快？
:
: create
|
c*****d
发帖数: 6045 | 73 没看太明白
是不是要删除transacitons表中某段时间的记录
如果要删除的记录超过10000条，10001条以后的就不删除了？
)
【在 b**a 的大作中提到】
: I am using sth like this now:
: DECLARE @count2 int
: SET @count2 = 10000
: WHILE @count2 >= 10000
: BEGIN
: DELETE temp from ( SELECT TOP 10000 * FROM Transactions WITH(NOLOCK)
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate)
: temp OPTION (MAXDOP 1)
: SELECT @count2 = @@ROWCOUNT
: END
|
b**a
发帖数: 1118 | 74 No. This is to delete 10000 each batch and keep deleting untill every
records that qualified get deleted.
【在 c*****d 的大作中提到】
: 没看太明白
: 是不是要删除transacitons表中某段时间的记录
: 如果要删除的记录超过10000条，10001条以后的就不删除了？
:
: )
|
i****a
发帖数: 36252 | 75 Then you have a bug in the while condition.
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: No. This is to delete 10000 each batch and keep deleting untill every
: records that qualified get deleted.
|
b**a
发帖数: 1118 | 76 what is it?
Thanks.
【在 i****a 的大作中提到】
: Then you have a bug in the while condition.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
i****a
发帖数: 36252 | 77 Never mind, its fine.
Just try different coding and batch sizes.
[发表自未名空间手机版 - m.mitbbs.com]
【在 b**a 的大作中提到】
: what is it?
: Thanks.
|
B*****g
发帖数: 34098 | 78 假设每个删除都删除不同的range呢？
【在 c*****d 的大作中提到】
: 同时run 10个，每个delete 4 millions record?
: 这个方法性能更慢
|
y****w
发帖数: 3747 | 79 10000的批次太小，换成10w或100w重新跑。问下你们的dba，保证log空间足够。
WITH(NOLOCK
)
@EndDate)
【在 b**a 的大作中提到】
: I am using sth like this now:
: DECLARE @count2 int
: SET @count2 = 10000
: WHILE @count2 >= 10000
: BEGIN
: DELETE temp from ( SELECT TOP 10000 * FROM Transactions WITH(NOLOCK)
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate)
: temp OPTION (MAXDOP 1)
: SELECT @count2 = @@ROWCOUNT
: END
|
y****w
发帖数: 3747 | 80 sql server的锁和oracle的很不一样。
【在 B*****g 的大作中提到】
: 同时run 10个会不会快？
:
: create
|
|
|
B*****g
发帖数: 34098 | 81 2008不是改善了吗？另外如果有partition可行吗？
【在 y****w 的大作中提到】
: sql server的锁和oracle的很不一样。
|
y****w
发帖数: 3747 | 82 并发delete总是要受影响的吧。各个并发之间必须有严格的界限，不然以set的无序特
性，跑跑就锁死了，或操作旧数据了。
lz这个没table partition，用partition/order by硬排序出来或许行，用rank避免最
后那组值的随机性.
没注意sql 2008支持不支持类似currently committed语义。
【在 B*****g 的大作中提到】
: 2008不是改善了吗？另外如果有partition可行吗？
|
j*****n
发帖数: 1781 | 83 partitioning will definitely improve the performance.
specially if the partition(s) hold only the records that will be deleted,
then the delete action will take no time via dropping the partition(s).
【在 B*****g 的大作中提到】
: 2008不是改善了吗？另外如果有partition可行吗？
|
y****w
发帖数: 3747 | 84 sql大拿说说sql server 2008/denali的锁机制，在并发读写方面的改进？
【在 j*****n 的大作中提到】
: partitioning will definitely improve the performance.
: specially if the partition(s) hold only the records that will be deleted,
: then the delete action will take no time via dropping the partition(s).
|
c*****d
发帖数: 6045 | 85 除非你知道每个range在哪个block上
【在 B*****g 的大作中提到】
: 假设每个删除都删除不同的range呢？
|
i****a
发帖数: 36252 | 86 I think mainly the time is spend on i/o. But can't tell without a perfmon
trace.
[发表自未名空间手机版 - m.mitbbs.com]
【在 B*****g 的大作中提到】
: 假设每个删除都删除不同的range呢？
|
B*****g
发帖数: 34098 | 87 他那个有时间range，可以人为地分成几个range，sql其实是不同的，数据相互间就可
以独立
【在 y****w 的大作中提到】
: 并发delete总是要受影响的吧。各个并发之间必须有严格的界限，不然以set的无序特
: 性，跑跑就锁死了，或操作旧数据了。
: lz这个没table partition，用partition/order by硬排序出来或许行，用rank避免最
: 后那组值的随机性.
: 没注意sql 2008支持不支持类似currently committed语义。
|
B*****g
发帖数: 34098 | 88 server上很多CPU的
【在 i****a 的大作中提到】
: I think mainly the time is spend on i/o. But can't tell without a perfmon
: trace.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
B*****g
发帖数: 34098 | 89 zkss
【在 c*****d 的大作中提到】
: 除非你知道每个range在哪个block上
|
i****a
发帖数: 36252 | 90 Not cpu. I'm refering to disk i/o.
Without optimizing query, most likely the bottle neck is at i/o. Running
mulitple instances of the query wouldn't help if they all wait for the disk.
[发表自未名空间手机版 - m.mitbbs.com]
【在 B*****g 的大作中提到】
: server上很多CPU的
|
|
|
B*****g
发帖数: 34098 | 91 这个table显然是需要partition，哈哈
【在 j*****n 的大作中提到】
: partitioning will definitely improve the performance.
: specially if the partition(s) hold only the records that will be deleted,
: then the delete action will take no time via dropping the partition(s).
|
B*****g
发帖数: 34098 | 92 多几个SQL就把Disk搞死了，呵呵
disk.
【在 i****a 的大作中提到】
: Not cpu. I'm refering to disk i/o.
: Without optimizing query, most likely the bottle neck is at i/o. Running
: mulitple instances of the query wouldn't help if they all wait for the disk.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
y****w
发帖数: 3747 | 93 lz这个瓶颈我认为是因为batch size太小带来的循环冗余开销。原先那个sql跑起来估计机器的
cpu/io都不能真正忙起来，但换个角度过来说，总体cpu/io比一次删除的要多了n多倍。
他那个表有400M rows，是个大型库，机器应该差不到哪里去，日志配置应该也不会太
小气。删10M记录应该比做1000次每次10000条要快的多，lz的要求也就是提高一半，改
下batch size应该够用了。lz应该试试然后贴个结果上来。
Running
the
disk.
【在 i****a 的大作中提到】
: Not cpu. I'm refering to disk i/o.
: Without optimizing query, most likely the bottle neck is at i/o. Running
: mulitple instances of the query wouldn't help if they all wait for the disk.
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
B*****g
发帖数: 34098 | 94 这个需要测试，据俺测试oracle9i，一般来说1w和10w差不多。另外lz的code为啥要
hardcode 10000很多次？
估计机器的
倍。
【在 y****w 的大作中提到】
: lz这个瓶颈我认为是因为batch size太小带来的循环冗余开销。原先那个sql跑起来估计机器的
: cpu/io都不能真正忙起来，但换个角度过来说，总体cpu/io比一次删除的要多了n多倍。
: 他那个表有400M rows，是个大型库，机器应该差不到哪里去，日志配置应该也不会太
: 小气。删10M记录应该比做1000次每次10000条要快的多，lz的要求也就是提高一半，改
: 下batch size应该够用了。lz应该试试然后贴个结果上来。
:
: Running
: the
: disk.
|
y****w
发帖数: 3747 | 95 随手的脚本写法，保证能删光，又不想费事儿去搞到精确的批次，要不加个@@rowcount
=0跳出来也就行了。
【在 B*****g 的大作中提到】
: 这个需要测试，据俺测试oracle9i，一般来说1w和10w差不多。另外lz的code为啥要
: hardcode 10000很多次？
:
: 估计机器的
: 倍。
|
y****w
发帖数: 3747 | 96 这么多的行删除，需要的行锁太多; 如果锁升级的话影响怎样,页锁/表锁会破坏本来sql语句之间的
隔离？。 sql server没那么熟，不好说。
【在 B*****g 的大作中提到】
: 他那个有时间range，可以人为地分成几个range，sql其实是不同的，数据相互间就可
: 以独立
|
B*****g
发帖数: 34098 | 97 等待大牛中
sql语句之间的
【在 y****w 的大作中提到】
: 这么多的行删除，需要的行锁太多; 如果锁升级的话影响怎样,页锁/表锁会破坏本来sql语句之间的
: 隔离？。 sql server没那么熟，不好说。
|
a9
发帖数: 21638 | 98 先把不重要的索引删掉。
【在 b**a 的大作中提到】
: Now we can only delete them in 1 hour. How to make it in 30 mins?
: Thanks,
: Ming
: Update:
: Tried all i can except partitioned table. We cannot drop the index and rebuild it because other hourly sql job is going to insert a lot of records in the same table. Seemed no way to ensure it will finish in 30 mins so my solution is to add a waitfor delay 0.2 in every loop. In this way, the delete will finish much longer (2:30) but it will not affect any other jobs.
|
c*****d
发帖数: 6045 | 99 假如你run 10个batch，这些batch都在修改同一个db block or db page
【在 B*****g 的大作中提到】
: zkss
|
c*****d
发帖数: 6045 | 100 时间字段上的range －－－逻辑
data blocks range －－－物理
一般情况下是不会一一对应的
很可能一个block上有今天的数据，也有100年以前的数据
【在 B*****g 的大作中提到】
: 他那个有时间range，可以人为地分成几个range，sql其实是不同的，数据相互间就可
: 以独立
|
|
|
y****w
发帖数: 3747 | 101 数据量小时行锁就行了。lz这个行锁肯定不够用，要上页锁甚至表锁。看dbms具体实现lock wait
的时间可能差很多。 逻辑上独立这个前提就有可能导致实现上的优化。所以我说还是得真懂sql
server的来说说sql server目前以及可预期版本的实现。
再说今天很对的东西，过几年也许就变成错的了。
【在 c*****d 的大作中提到】
: 时间字段上的range －－－逻辑
: data blocks range －－－物理
: 一般情况下是不会一一对应的
: 很可能一个block上有今天的数据，也有100年以前的数据
|
B*****g
发帖数: 34098 | 102 同一时间在一起的可能性很大。LZ每次就锁1w个，delete01也许会lock delete02、03
，但总不会把02-10（假设开10个）都lock住吧。当然，对SQL server的lock不是很精
通，期待大牛详解SQL server Lock。另外如果SQL搞不定，可以考虑hibernate。
【在 c*****d 的大作中提到】
: 时间字段上的range －－－逻辑
: data blocks range －－－物理
: 一般情况下是不会一一对应的
: 很可能一个block上有今天的数据，也有100年以前的数据
|
c*****d
发帖数: 6045 | 103 “同一时间在一起的可能性很大”，未必，看应用
OLTP一个block上什么时间的数据都会有
03
【在 B*****g 的大作中提到】
: 同一时间在一起的可能性很大。LZ每次就锁1w个，delete01也许会lock delete02、03
: ，但总不会把02-10（假设开10个）都lock住吧。当然，对SQL server的lock不是很精
: 通，期待大牛详解SQL server Lock。另外如果SQL搞不定，可以考虑hibernate。
|
c*****d
发帖数: 6045 | 104 我没搞清楚lz是必须用sql delete的方法来删除
还是可以用其他方法来实现？ |
B*****g
发帖数: 34098 | 105 据说hibernate比SQL快
【在 c*****d 的大作中提到】
: 我没搞清楚lz是必须用sql delete的方法来删除
: 还是可以用其他方法来实现？
|
y****w
发帖数: 3747 | 106 这sql得写多烂？
【在 B*****g 的大作中提到】
: 据说hibernate比SQL快
|
b**a
发帖数: 1118 | 107 yes we have to do it in sql.
【在 c*****d 的大作中提到】
: 我没搞清楚lz是必须用sql delete的方法来删除
: 还是可以用其他方法来实现？
|
y****w
发帖数: 3747 | 108 have you tried bigger batch size? start with 1M.
【在 b**a 的大作中提到】
: yes we have to do it in sql.
|
b**a
发帖数: 1118 | 109 Log drive does not have that big space...
Thanks.
Ming
【在 y****w 的大作中提到】
: have you tried bigger batch size? start with 1M.
|
j*******7
发帖数: 6300 | 110 那个Delete语句可以这么写：
DELETE TOP(10000) FROM Transactions
WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate
Not sure if it's faster. The "select *" is bad in my eyes. |
|
|
b**a
发帖数: 1118 | 111 http://sqlblogcasts.com/blogs/simons/archive/2009/05/22/DELETE-
According to that link, that is faster actually than delete directly...
【在 j*******7 的大作中提到】
: 那个Delete语句可以这么写：
: DELETE TOP(10000) FROM Transactions
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate
: Not sure if it's faster. The "select *" is bad in my eyes.
|
j*******7
发帖数: 6300 | 112 Thank you. An old dog can still learn a new trick.
【在 b**a 的大作中提到】
: http://sqlblogcasts.com/blogs/simons/archive/2009/05/22/DELETE-
: According to that link, that is faster actually than delete directly...
|
y****w
发帖数: 3747 | 113 应该测试下，网上错的东西太多了，昨天对的今天也许就错了。这两种应该几乎没什么
差别才对，假如sql optimizer没干傻事的话。
【在 j*******7 的大作中提到】
: 那个Delete语句可以这么写：
: DELETE TOP(10000) FROM Transactions
: WHERE TransStartTime >= @FromDate and TransStartTime < @EndDate
: Not sure if it's faster. The "select *" is bad in my eyes.
|
B*****g
发帖数: 34098 | 114 顶，tuning就是调试
【在 y****w 的大作中提到】
: 应该测试下，网上错的东西太多了，昨天对的今天也许就错了。这两种应该几乎没什么
: 差别才对，假如sql optimizer没干傻事的话。
|
t****3
发帖数: 2337 | |
b**a
发帖数: 1118 | 116 This is a variation from this article. Sounds very reasonable so I did not
do test.
Plus i do not have enough space and data in our dev platform to test so...
I am not a sql guy...
【在 y****w 的大作中提到】
: 应该测试下，网上错的东西太多了，昨天对的今天也许就错了。这两种应该几乎没什么
: 差别才对，假如sql optimizer没干傻事的话。
|
B*****g
发帖数: 34098 | 117 加入CINAOUG，你也可以成为sql guy
【在 b**a 的大作中提到】
: This is a variation from this article. Sounds very reasonable so I did not
: do test.
: Plus i do not have enough space and data in our dev platform to test so...
: I am not a sql guy...
|
g***l
发帖数: 18555 | 118 建一个一模一样的TABLE名字是TABLE_TEMP，注意PK, INDEXES， BULK INSERT（或者BCP）你想留住
的RECORD INTO TABLE_TEMP，DROP OLD TABLE, RENAME TABLE_TEMP TO TABLE,
RECOMPILE TABLE,没做好INDEX，又没弄PARTITION的，只嫩用这种方法 |
s*****o
发帖数: 303 | 119 试过disable index， 然后 rebuild 么？不是drop index |
g***l
发帖数: 18555 | 120 没有INDEX不删的更慢么，DELETE WHERE上要有INDEX，然后BATCH的删 |
|
|
s*****o
发帖数: 303 | 121 是的，只留要用的index. 要是删除很多record，还不如重建一个table放不删的数据快
【在 g***l 的大作中提到】
: 没有INDEX不删的更慢么，DELETE WHERE上要有INDEX，然后BATCH的删
|
