Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Правильная организация ребилда базы  [new]
ACV
Member

Откуда:
Сообщений: 74
Всем привет!
Имеется SQL Server 2008 SP2 Standard
Имеется база (примерно 220 Гб)
Требуется раз в неделю проводить ребилд базы.
Делать через создание отдельного Maintenance Plan не хочу т.к. ребилд должен идти ночью в связке с ещё некоторыми заданиями (бэкап , очистка кеша , обновл. статистики и др.)
Хочется запускать его скриптом.
Ранее работал с SQL 2000 и там делал это так
USE TorgDP
DECLARE @TableName char(64)
DECLARE SysCur CURSOR FOR SELECT name FROM sysobjects WHERE type='U'
OPEN SysCur
FETCH NEXT FROM SysCur INTO @TableName
WHILE @@FETCH_STATUS=0 BEGIN
DBCC DBREINDEX(@TableName,' ',80)
FETCH NEXT FROM SysCur INTO @TableName
END
CLOSE SysCur
DEALLOCATE SysCur

подскажите можно ли делать ребилд на SQL Server 2008 SP2 Standard такими командами или нет?
Вообще в 2008 весь ребилд идет по команде
ALTER INDEX
но как тогда будет выглядить скрипт для ребилда всей базы?
Помогите пожалуйста.

Заранее спасибо!
11 июл 11, 14:09    [10955657]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Shakill
Member

Откуда: мск
Сообщений: 1887
ACV, а почему базе требуется делать ребилд раз в неделю по всем индексам?

посмотрите здесь пример Г
11 июл 11, 14:20    [10955752]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
egaraev
Member

Откуда:
Сообщений: 63
Или так:

DECLARE @cmd varchar(8000)
declare @vdb int
set @vdb=db_id()
CREATE TABLE #all_idx (
[db_id] int,
[schema_id] int,
[object_id] int,
index_name sysname,
avg_fragmentation_in_percent float,
avg_page_space_used_in_percent float NULL,
page_count bigint
)
INSERT INTO #all_idx
SELECT frag.database_id, obj.schema_id,
frag.object_id, idx.name,
frag.avg_fragmentation_in_percent, frag.avg_page_space_used_in_percent, frag.page_count
FROM sys.dm_db_index_physical_stats (@vdb, NULL, NULL, NULL, 'LIMITED') frag
, sys.indexes idx, sys.objects obj
where
idx.object_id = frag.object_id
and idx.object_id = obj.object_id
and idx.index_id = frag.index_id
and frag.index_id>0
and frag.index_level=0
order by avg_fragmentation_in_percent DESC

DECLARE idx CURSOR
for
select 'ALTER INDEX ['+index_name+'] ON ['+DB_NAME([db_id])+'].['+
SCHEMA_NAME([schema_id])+'].['+OBJECT_NAME([object_id], [db_id])+
'] REBUILD WITH (FILLFACTOR = 80, PAD_INDEX=ON, SORT_IN_TEMPDB=ON);'
from #all_idx
where avg_fragmentation_in_percent>=30.0 and page_count>100

open idx
FETCH NEXT FROM idx INTO @cmd
WHILE (@@FETCH_STATUS <> -1)
BEGIN
IF (@@FETCH_STATUS <> -2)
BEGIN
exec(@cmd)
END
FETCH NEXT FROM idx INTO @cmd
END
CLOSE idx
DEALLOCATE idx

drop table #all_idx
11 июл 11, 15:12    [10956155]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
egaraev
WITH (FILLFACTOR = 80
Ай-ай-ай... Нафиг он такой маленький-то нужен?
11 июл 11, 15:18    [10956220]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Crimean
Member

Откуда:
Сообщений: 13147
Гавриленко Сергей Алексеевич
egaraev
WITH (FILLFACTOR = 80
Ай-ай-ай... Нафиг он такой маленький-то нужен?


пусть - пусть. зато после можно будет перестроить в 100% и на ровном месте получить премию за серьезную оптимизацию системы
11 июл 11, 15:35    [10956325]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
ACV
Member

Откуда:
Сообщений: 74
Подскажите пожалуйста , а скрипт от SQL 2000 не подойдет?
11 июл 11, 16:25    [10956836]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
ACV
Member

Откуда:
Сообщений: 74
Для СКЛ 2008 решил сделать так

USE db1cut
GO
DECLARE @MyTable varchar(252)
DECLARE @MyIndex varchar(252)
DECLARE @DSQL varchar(8000)
DECLARE MyCursor CURSOR FOR
SELECT o.name, i.name
FROM sysobjects o INNER JOIN sysindexes i ON o.id = i.id
WHERE (o.xtype = 'U') AND (INDEXPROPERTY(i.id, i.name, 'isStatistics') = 0) AND (i.dpages > 0)
ORDER BY o.name, i.indid

OPEN MyCursor
FETCH NEXT FROM MyCursor INTO @MyTable, @MyIndex
WHILE @@FETCH_STATUS=0

BEGIN
PRINT 'Перестройка индекса '+@MyIndex+' из таблицы '+@MyTable
SET @DSQL = ' BEGIN TRY
ALTER INDEX '+@MyIndex+' ON '+@MyTable+
' REBUILD WITH (ONLINE = ON,
SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON)
END TRY

BEGIN CATCH ALTER INDEX '+@MyIndex+' ON '+@MyTable+
' REBUILD WITH (ONLINE = OFF,
SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON) END CATCH;'
EXEC(@DSQL)

FETCH NEXT FROM MyCursor INTO @MyTable, @MyIndex

END
CLOSE MyCursor
DEALLOCATE MyCursor

если можно аргументировано покритикуйте такой скрипт...
11 июл 11, 17:04    [10957117]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Shakill
Member

Откуда: мск
Сообщений: 1887
ACV,

1) курсорный селект выводит записи для таблиц без индексов
2) почему вы решили, что если не получится ребилд онлайн, то нужно тут же пытаться делать офлайновый?
3) в литературе всё понятно описано
http://msdn.microsoft.com/ru-ru/library/ms189858.aspx
Первым шагом в определении, какой метод дефрагментации следует использовать, будет анализ индекса на предмет степени фрагментации
, а вы стараетесь нагрузить сервер кучей ненужной работы
11 июл 11, 17:15    [10957228]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
egaraev
Member

Откуда:
Сообщений: 63
ACV
Подскажите пожалуйста , а скрипт от SQL 2000 не подойдет?


Нет, это для 2005/2008.
11 июл 11, 17:28    [10957351]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
egaraev
Member

Откуда:
Сообщений: 63
Crimean
Гавриленко Сергей Алексеевич
пропущено...
Ай-ай-ай... Нафиг он такой маленький-то нужен?


пусть - пусть. зато после можно будет перестроить в 100% и на ровном месте получить премию за серьезную оптимизацию системы


Вы это о чем ребята?
20% обычно резервируют для апдейтов что бы фрагментация не так быстро росла. Читайте мануалы!
11 июл 11, 17:31    [10957365]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
egaraev
Вы это о чем ребята?
20% обычно резервируют для апдейтов что бы фрагментация не так быстро росла. Читайте мануалы!
А мужыки-то не знают.
11 июл 11, 17:33    [10957380]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Glory
Member

Откуда:
Сообщений: 104751
egaraev
Вы это о чем ребята?
20% обычно резервируют для апдейтов что бы фрагментация не так быстро росла. Читайте мануалы!

Вот так взять и добавить ко всем таблицам еще по 20% ? Чтобы побольше места занимали и побольше чтений было с диска ?
11 июл 11, 17:39    [10957406]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
egaraev
Читайте мануалы!
А дайте ссылочку, кстати, на эти мануалы. Очень интересная рекомендация. Сразу уменьшает эффективность использования памяти на 20%, а так же как минимум на столько же увеличивает нагрузку на диски.
11 июл 11, 17:39    [10957410]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
egaraev
Member

Откуда:
Сообщений: 63
Гавриленко Сергей Алексеевич
egaraev
Читайте мануалы!
А дайте ссылочку, кстати, на эти мануалы. Очень интересная рекомендация. Сразу уменьшает эффективность использования памяти на 20%, а так же как минимум на столько же увеличивает нагрузку на диски.


Во первых разговор идет но о таблицах а о индексах!
Во втотрых при вставках и апдейтах если индекс построен с 100% заполнением, при каждой вставке и при некотрых обновлениях будте происходить page split явление не очень приятное.
Читайте BOL:

A correctly chosen fill-factor value can reduce potential page splits by providing enough space for index expansion as data is added to the underlying table.When a new row is added to a full index page, the Database Engine moves approximately half the rows to a new page to make room for the new row. This reorganization is known as a page split. A page split makes room for new records, but can take time to perform and is a resource intensive operation. Also, it can cause fragmentation that causes increased I/O operations. When frequent page splits occur, the index can be rebuilt by using a new or existing fill-factor value to redistribute the data.
11 июл 11, 17:51    [10957471]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
egaraev
Во первых разговор идет но о таблицах а о индексах!
Т.е. кластерные индексы пусть себе живут без мейнтененса, да?

egaraev
Во втотрых при вставках и апдейтах если индекс построен с 100% заполнением, при каждой вставке и при некотрых обновлениях будте происходить page split явление не очень приятное.
Читайте BOL:

A correctly chosen fill-factor value can reduce potential page splits by providing enough space for index expansion as data is added to the underlying table.When a new row is added to a full index page, the Database Engine moves approximately half the rows to a new page to make room for the new row. This reorganization is known as a page split. A page split makes room for new records, but can take time to perform and is a resource intensive operation. Also, it can cause fragmentation that causes increased I/O operations. When frequent page splits occur, the index can be rebuilt by using a new or existing fill-factor value to redistribute the data.
Не-не-не. Вы зубы не заговаривайте. Вы про 80% давайте ссылку.
11 июл 11, 17:56    [10957520]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Glory
Member

Откуда:
Сообщений: 104751
egaraev

Во первых разговор идет но о таблицах а о индексах!

Ну да, кластерный индекс - это ни разу ни таблица

egaraev
Во втотрых при вставках и апдейтах если индекс построен с 100% заполнением, при каждой вставке и при некотрых обновлениях будте происходить page split явление не очень приятное.

И вы добавляете и апдейтите во всех запросах именно заполненные страницы ?
Что ни запрос, то сразу page split ? Или вы так боитесь одночных page split-ов, что готовы на каждой(!) странице держать 20% свободного места ?
11 июл 11, 17:57    [10957532]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
egaraev
Member

Откуда:
Сообщений: 63
Гавриленко Сергей Алексеевич
Не-не-не. Вы зубы не заговаривайте. Вы про 80% давайте ссылку.


Можно помониторить кол-во page split, 80% это я для себя такую формулу, для многих систем с которыми я работаю этого вполне достаточно. Иногда использую и др. значения, все зависит от конкретной БД.
11 июл 11, 18:10    [10957651]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Гавриленко Сергей Алексеевич
Member

Откуда:
Сообщений: 37254
egaraev
Можно помониторить кол-во page split, 80% это я для себя такую формулу, для многих систем с которыми я работаю этого вполне достаточно. Иногда использую и др. значения, все зависит от конкретной БД.
Достаточно, чтобы уронить перфоманс на 20%? Достаточно, да.
11 июл 11, 18:13    [10957672]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2680
ACV,

Я бы курсорчик описал все-таки примерно так (чтобы схемы учесть, если что):

declare SysCur cursor for 
  SELECT '['+db_name()+'].['+s.name+'].['+o.name+']', i.name
  FROM sys.sysobjects o INNER JOIN sys.sysindexes i ON o.id = i.id
  INNER JOIN sys.schemas s ON o.UID = s.schema_id
  WHERE (o.xtype = 'U') AND (INDEXPROPERTY(i.id, i.name, 'isStatistics') = 0) AND (i.dpages > 0)
  ORDER BY o.name, i.indid

или

select '['+db_name()+'].['+sys.schemas.name+'].['+sys.sysobjects.name+']'
  from  sys.sysobjects, sys.schemas
  where sys.sysobjects.uid = sys.schemas.schema_id and
  sys.sysobjects.xtype = 'U' 
   order by (select sum(dpages) from sysindexes where sysindexes.id = sysobjects.id) DESC

и тогда уже говорить 

ALTER INDEX ALL ON '+@MyTable+.......
11 июл 11, 18:43    [10957826]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Mega_Max
Member

Откуда:
Сообщений: 16
Коллеги подскажите в чем может быть проблема.
Для реорганизации или ребилда базы использую алгоритм, где запрос сам смотрит что ему делать REBUILD или REORGANIZE, основан на таблице sys.dm_db_index_physical_stats с джинами для определенных таблиц.
Все работало хорошо до этой недели примерно (максимум 1.5 часа). Сейчас запрос стал работать не менее трех часов.

Для проверки запустил обычный запрос, который работает 12+ минут (не хватает терпения я его отключаю):
select *
from sys.dm_db_index_physical_stats(DB_ID(N'Имя_базы'),  object_id(N'имя_таблицы') , NULL, NULL, NULL)  
Собственно вопрос из за чего такое может быть? как побороть проблему?
10 авг 11, 18:43    [11100147]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
gds
Member

Откуда: Железнодорожный
Сообщений: 1842
Блог
Раз речь пошла про ребилд индекса. Тгда и мой покретикуйте, плиз.
create view dbatools.v_partition_scheme_info 
as
select 
		prtsch.data_space_id as [DATA_SPACE_ID],
		prtsch.name as [SCHEME_NAME],
		prtfn.name as [FUNC_NAME],
		prtfn.fanout as [FUNC_PART],
		tp.Name as [TYPE],
		prtrange.boundary_id as [RANGE_BOUNDARY],
		prtrange.value as [RANGE_VALUE]
from sys.partition_schemes as prtsch
	join sys.partition_functions as prtfn on prtfn.function_id = prtsch.function_id
	join sys.partition_parameters as prtpar on prtpar.function_id = prtfn.function_id
	join sys.partition_range_values as prtrange on prtrange.function_id = prtfn.function_id
	join sys.types as tp on tp.system_type_id = prtpar.system_type_id and tp.user_type_id = prtpar.system_type_id
go

grant select on dbatools.v_partition_scheme_info to public
go

create view dbatools.v_index_for_services 
as
select 	
		sch.principal_id as [schema_principal],
		sch.schema_id as [schema_id],
		sch.Name as [schema_name],
		ix.object_id as [object_id],
		o.Name as [object_name],
		ix.index_id as [index_id],
		ix.Name as [index_name],
		case ds.type
			when 'FG' then ds.name
			when 'PS' then (select distinct scheme_name from dbatools.v_partition_scheme_info where data_space_id = ix.data_space_id)
		end as data_space,
		isnull((select max(func_part) from dbatools.v_partition_scheme_info where data_space_id = ix.data_space_id),-1) as max_part_number,
		ix.is_disabled,
		ix.allow_page_locks
from sys.indexes as ix
join sys.all_objects as o on o.object_id = ix.object_id
join sys.schemas as sch on sch.schema_id = o.schema_id
join sys.data_spaces as ds on ds.data_space_id = ix.data_space_id
where 
	o.type = N'U' 
and	o.type_desc = N'USER_TABLE' 
and	ix.name is not null 
go

grant select on dbatools.v_index_for_services to public
go

create view dbatools.v_index_for_services_only_used

as
select 
	iu.database_id,	
	i.object_id,
	i.schema_name,
	i.object_name,
	i.[schema_name]+'.'+i.[object_name] as [full_object_name],	
	i.index_id,
	i.index_name,
	case i.max_part_number
		when -1 then 0
		else i.max_part_number
	end as max_part_number,
	i.is_disabled, -- = 0
	i.[allow_page_locks] -- = 1
from dbatools.v_index_for_services as i
join sys.dm_db_index_usage_stats as iu on iu.index_id = i.index_id and iu.object_id = i.object_id and iu.database_id = DB_ID()
where 
	(	iu.user_seeks != 0 or 
		iu.user_scans != 0 or 
		iu.user_lookups != 0 or 
		iu.system_seeks != 0 or 
		iu.system_scans != 0  or 
		iu.system_lookups != 0)
go
grant select on dbatools.v_index_for_services_only_used to public
go		

Сам скрипт. Сразу оговорюсь. Все партиции у нас по времени и необходимость перестроения только последней секции.
create procedure dbatools.sp_smart_reindex(
	@type_name char(4)='full'
)
as
declare @lp_database_id			smallint,
		@lp_object_id			int,
		@lp_object_name			nvarchar(514),
		@lp_index_id			int,
		@lp_index_name			sysname,
		@lp_max_part_number		int,
		@lp_is_disabled			bit,
		@lp_allow_page_locks	bit,
		@lp_avg_defrag_percent	decimal(10,3),
		@run_sql				nvarchar(1024),
		@oper_num				bigint,
		@ident					bigint,
		@oper_type				smallint

declare c1 INSENSITIVE cursor for 
select 
	a.database_id,
	a.object_id,
	'['+a.schema_name +'].['+a.object_name+']' as object_name,
	a.index_id,
	'['+a.index_name+']' as index_name,
	a.max_part_number,
	a.is_disabled,
	a.allow_page_locks
from dbatools.v_index_for_services_only_used a
where a.object_id not in (select obj_id from dbatools.rep_service_index_exclude)

if @type_name not in ('full','part')
	raiserror (N'Parameter @type_name has been "full" or "part"',10,1)

set nocount on

exec dbatools.sp_next_value_sequence
	@sequence_name = N'reindex_OperNum',
	@new_value =@oper_num  output

open c1
FETCH NEXT FROM c1
INTO @lp_database_id,@lp_object_id,@lp_object_name,
	@lp_index_id,@lp_index_name,@lp_max_part_number,
	@lp_is_disabled,@lp_allow_page_locks
WHILE @@FETCH_STATUS = 0
BEGIN

if @type_name = 'part'
	select @lp_avg_defrag_percent=avg(avg_fragmentation_in_percent) 
	from master.sys.dm_db_index_physical_stats(
			@lp_database_id,
		@lp_object_id,
		@lp_index_id,
		@lp_max_part_number,
		'limited') as s
else
	select @lp_avg_defrag_percent=avg(avg_fragmentation_in_percent) 
	from master.sys.dm_db_index_physical_stats(
			@lp_database_id,
		@lp_object_id,
		@lp_index_id,
		null,
		'limited') as s

if @lp_avg_defrag_percent < 5 or @lp_is_disabled = 1
begin
	FETCH NEXT FROM c1
	INTO @lp_database_id,@lp_object_id,@lp_object_name,
		@lp_index_id,@lp_index_name,@lp_max_part_number,
		@lp_is_disabled,@lp_allow_page_locks	
	continue;	
end else if @lp_avg_defrag_percent >= 5 and @lp_avg_defrag_percent < 30
begin
 if @lp_allow_page_locks = 1 begin
	set @run_sql = N'alter index '+ @lp_index_name + N' on '+@lp_object_name + N'  reorganize ';
	set @oper_type = 10;
 end else begin
	set @run_sql = N'alter index '+ @lp_index_name + N' on '+@lp_object_name + N'  rebuild ';	
	set @oper_type = 11;
 end
end else if @lp_avg_defrag_percent > 30 begin
		set @run_sql = N'alter index '+ @lp_index_name + N' on '+@lp_object_name + N'  rebuild ';
		set @oper_type = 11;
end
if @lp_max_part_number > 0 and @type_name= 'part'
	set @run_sql = @run_sql + N' partition = '+ cast(@lp_max_part_number as nvarchar)

begin try
	insert into dbatools.rep_service_index(table_name,idx_name,start_time,end_time,dbname,oper_num,oper_type) 
		values (@lp_object_name,@lp_index_name,getdate(),null,db_name(),@oper_num,@oper_type) 
		set @ident = Scope_identity()

	exec sp_executesql @run_sql
	
	update dbatools.rep_service_index
		set end_time = getdate()
	where	record_id = @ident
end try
begin catch
update dbatools.rep_service_index
	set [Description] = @run_sql
where	record_id = @ident

insert into dbatools.rep_errors(record_id,error_message) values (@ident,error_message())
end catch


FETCH NEXT FROM c1
INTO @lp_database_id,@lp_object_id,@lp_object_name,
	@lp_index_id,@lp_index_name,@lp_max_part_number,
	@lp_is_disabled,@lp_allow_page_locks
END
CLOSE c1;
DEALLOCATE c1;
go

grant execute on dbatools.sp_smart_reindex to public;
go
11 авг 11, 09:58    [11101830]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Mega_Max
Member

Откуда:
Сообщений: 16
gds
Раз речь пошла про ребилд индекса. Тгда и мой покретикуйте, плиз.

Как все сложно.
Сколько весит база? сколько таблиц? Сколько выполняется такой скрипт?
11 авг 11, 10:21    [11101944]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
gds
Member

Откуда: Железнодорожный
Сообщений: 1842
Блог
Mega_Max
gds
Раз речь пошла про ребилд индекса. Тгда и мой покретикуйте, плиз.

Как все сложно.
Сколько весит база? сколько таблиц? Сколько выполняется такой скрипт?

База ~ 400 Гигов, Таблиц 6380. Если каждый день запускать, то от 5 до 8 мин. Если раз в неделю 12-15 мин. Естественно при параметре part. При полном сканировании около 18 если каждый день. OLTP ~ 8 000 - 10 000 транзакций в день. При нагруженном дне 15 000 - 20 000. Нагрузка в течении дня равномерная, но бывают и всплески.
11 авг 11, 10:33    [11102030]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
gds
Member

Откуда: Железнодорожный
Сообщений: 1842
Блог
gds
Mega_Max
пропущено...

Как все сложно.
Сколько весит база? сколько таблиц? Сколько выполняется такой скрипт?

База ~ 400 Гигов, Таблиц 6380. Если каждый день запускать, то от 5 до 8 мин. Если раз в неделю 12-15 мин. Естественно при параметре part. При полном сканировании около 18 если каждый день. OLTP ~ 8 000 - 10 000 транзакций в день. При нагруженном дне 15 000 - 20 000. Нагрузка в течении дня равномерная, но бывают и всплески.

Это видимо потому что периодически запускается процедура. Если пройтись по всем таблицам
alter index all on [table_name] rebuild
то это занимает 25 мин 43 сек +/- 15 сек.
11 авг 11, 10:46    [11102134]     Ответить | Цитировать Сообщить модератору
 Re: Правильная организация ребилда базы  [new]
Mega_Max
Member

Откуда:
Сообщений: 16
gds
пропущено...
База ~ 400 Гигов, Таблиц 6380. Если каждый день запускать, то от 5 до 8 мин. Если раз в неделю 12-15 мин. Естественно при параметре part. При полном сканировании около 18 если каждый день. OLTP ~ 8 000 - 10 000 транзакций в день. При нагруженном дне 15 000 - 20 000. Нагрузка в течении дня равномерная, но бывают и всплески.


быстро довольно таки. Скажите как организована дисковая подсистема? на каком рейде база стоит, система и т.д.
11 авг 11, 11:11    [11102370]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить