'SQLServer'에 해당되는 글 5건
- 2011.03.30 Admin::Cache Flush 가 발생하는 경우
- 2010.06.04 SQL Server의 Procedure Cache 사이즈
- 2010.06.04 복제::#5 구현&삭제 스크립트
- 2010.06.04 복제::머지복제에러
- 2010.06.03 백업성공보고
You may experience a decrease in query performance after you perform certain database maintenance operations or regular transaction operations in SQL Server 2005
( http://support.microsoft.com/kb/917828 )
2006-10-15 06:03:29.330 spid59 SQL Server has encountered 4 occurrence(s) of cachestore flush for the 'Object Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.
2006-10-15 06:03:29.420 spid59 SQL Server has encountered 4 occurrence(s) of cachestore flush for the 'SQL Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.
2006-10-15 06:03:29.420 spid59 SQL Server has encountered 4 occurrence(s) of cachestore flush for the 'Bound Trees' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.
The whole procedure cache is cleared when certain database level operations are performed in the following scenarios:
· A database has the AUTO_CLOSE database option set to ON. When no user connection references or uses the database, the background task tries to close and shut down the database automatically.
· You run several queries against a database that has default options. Then, the database is dropped.
· A database snapshot for a source database is dropped.
Note Database snapshots are only available in Microsoft SQL Server 2005 Enterprise Edition.
· You change the database state to OFFLINE or ONLINE.
· You successfully rebuild the transaction log for a database.
· You restore a database backup.
· You run the DBCC CHECKDB statement.
Note This is true only in versions of SQL Server 2005 that are earlier than SQL Server 2005 SP2. After you install SQL Server 2005 SP2 or later versions, the whole procedure cache is not flushed when you run the DBCC CHECKDB statement.
· You detach a database.
· You specify one of the following options when you run the ALTER DATABASE statement:
o OFFLINE
o ONLINE
o MODIFY FILEGROUP DEFAULT
o MODIFY_NAME
o MODIFY FILEGROUP READ_WRITE
o COLLATE
o MODIFY FILEGROUP READ_ONLY
o READ_ONLY
o READ_WRITE
· The whole procedure cache is cleared if one of the following server options is changed by the RECONFIGURE statement:
o cross db ownership chaining
o index create memory (KB)
o remote query timeout (s)
o user options
o max text repl size (B)
o cost threshold for parallelism
o max degree of parallelism
o min memory per query (KB)
o query wait (s)
o min server memory (MB)
o max server memory (MB)
o query governor cost limit
Note Procedure cache will not be cleared if the actual value does not change or if the new value for the max server memory server option is set to 0.
'Common Admin' 카테고리의 다른 글
Admin::2000용 TEST DB 생성. (0) | 2011.10.05 |
---|---|
Admin:: SQL Server 에러로 다른 서버에서 Rebuilding 처리 (0) | 2011.08.14 |
Admin::Configuring Windows 2003 ( x64 ) for SQL Server (0) | 2010.12.28 |
Admin:: LOG Rebuild (0) | 2010.11.23 |
Procedure Cache
SQL 서버는 두가지 타입의 cache에 메모리를 할당한다.
1. procedure cache
2. buffer cache
procedure cache는 실행한 stored procedure의 쿼리 실행 계획이 저장되는 공간이고,
buffer cache는 디스크로부터 읽어 들인 데이터를 저장하는 공간이다.
그런데 SQL Server를 세팅하고 관리할 때 SQL Server 인스턴스에 할당할 전체 메모리의 크기는 설정할 수 있지만, 위 두가지 메모리 영역 별로 메모리를 할당 하는 방법 및 수단은 존재하지 않는다.
(심지어 두 영역에 어떤 비율이나 공식이나 방법으로 메모리가 할당되는지에 대한 문서조차 없다.)
각설하고...
SQL Server가 메모리를 할당하는 방식은... procedure cache에 할당할 메모리 크기를 서버환경으로부터 일정 공식을 사용하여 계산하여 할당하고, 나머지 공간을 buffer cache에 할당하는 방식이다.
procedure cache 크기를 계산 방법은 아래와 같다.
- 32bit 플랫폼
procedure cache는 AWE (Address Windowing Extension)영역에 존재할 수 없다.
따라서 SQL인스턴스에 할당된 메모리의 첫 2GB까지의 영역만을 사용할 수 있는데, 이 영역의 50%와 1GB 중 작은 양이 procedure cache로 할당된다.
- 64bit 플랫폼
SQL Server 2005 SP1 또는 그 이전인 경우, "SQL 인스턴스에 할당된 첫 8GB까지의 75% + 이후 56GB까지의 50% + 나머지 메모리의 25%"를 procedure cache에 할당한다.
예를 들어 시스템 메모리가 16GB이고 SQL 인스턴스에 할당된 메모리 15GB인 경우, procedure cache의 크기는 9.5GB (8GB * 0.75 + 7GB * 0.5)가 된다.
단, SQL Server 2005 SP2에서 이 계산 방식이 "SQL 인스턴스에 할당된 첫 4GB까지의 75% + 나머지 메모리의 10%"로 바뀌어, 위의 예와 같은 상황에서 procedure cache의 크기는 4.1GB (4GB * 0.75 + 11GB * 0.1)가 된다.
(출처 : http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1316780,00.html
http://purumae.tistory.com/26)
이 글은 스프링노트에서 작성되었습니다.
'Common Admin' 카테고리의 다른 글
SQL 2008 -New DataType-Date (0) | 2010.06.04 |
---|---|
SQLDMO (0) | 2010.06.04 |
Admin::master db rebuild 방법 (0) | 2010.06.04 |
Profiler (0) | 2010.06.04 |
복제 삭제
- 방법 1: http://msdn.microsoft.com/ko-kr/library/ms152757.aspx
- 방법 2: http://support.microsoft.com/kb/324401
-
이상하게 잘 못 삭제했을 경우
-
select replinfo,* from sysobjects where replinfo = 0 을 찾아서 입력합니다.
-
sp_removedbreplication [ [ @dbname = ] 'dbname' ] [ , [ @type = ] type ]
-
-
-
- [ @dbname=] 'dbname'
-
-
- 데이터베이스의 이름입니다. dbname은 sysname이며 기본값은 NULL입니다. NULL인 경우 현재 데이터베이스를 사용합니다.
-
-
- [ @type = ] type
-
-
- 데이터베이스 개체를 제거 중인 복제의 유형입니다. type은 nvarchar(5)이며 다음 값 중 하나일 수 있습니다.
- tran
- 트랜잭션 복제 게시 개체를 제거합니다.
- merge
- 병합 복제 게시 개체를 제거합니다.
- both(기본값)
- 모든 복제 게시 개체를 제거합니다.
-
ERROR CASE
게시& 배포자가 먼저 삭제되고 구독이 남아 있을 경우
이 글은 스프링노트에서 작성되었습니다.
'Replication' 카테고리의 다른 글
복제::숨겨진 저장프로시저 확인 (0) | 2011.01.16 |
---|---|
복제::LOB DataType 제한 (0) | 2010.06.04 |
복제::머지복제에러 (0) | 2010.06.04 |
복제::스냅숏 DB를 사용한 게시 초기화 (0) | 2010.06.04 |
FIX: Error message when you try to insert data on a subscriber of a merge replication in SQL Server 2005: "Msg 548, Level 16, State 2, Line 1. The insert failed"
On This Page
SYMPTOMS
The insert failed. It conflicted with an identity range check constraint in database 'DatabaseName', replicated table 'Schema.TableName', column 'ColumnName'. If the identity column is automatically managed by replication, update the range as follows: for the Publisher, execute sp_adjustpublisheridentityrange; for the Subscriber, run the Distribution Agent or the Merge Agent.
This problem occurs when multiple Merge Agents synchronize data at the same time for the same merge publication. This problem can be exacerbated if you have many subscribers to the merge publication.
CAUSE
RESOLUTION
WORKAROUND
sp_changemergepublication '<PublicationName>', 'max_concurrent_merge', 1
Note After you use this workaround, performance may decrease if you have many subscribers for the publication. This behavior occurs because only one subscriber can synchronize data at a time.
STATUS
MORE INFORMATION
How to determine whether you are experiencing this problem
To determine whether you are experiencing this problem, follow these steps:1. | Verify that the current identity value is smaller than the lower bound of the first identity range of the identity range check constraint. To obtain the current identity value, run the following statement:
To obtain the identity ranges of the identity range check constraint, run either of the following statements:
Statement 1
Statement 2
|
2. | Use a SQL Server Profiler trace to determine whether interleaved executions of the sp_MSsetup_publisher_idrange stored procedure are started by separate Merge Agent sessions for the same publication. However, interleaved executions of the sp_MSsetup_publisher_idrange stored procedure do not always indicate that you are experiencing this problem. This is because SQL Server Profiler was not running when the original occurance of the merge synchronization generated the first error message. However, interleaved executions of the sp_MSsetup_publisher_idrange stored procedure do increase the possibility of experiencing this problem. |
3. | You can find overlapping merge synchronizations that occur when you receive the "548" error message occurs. To do this, you can review the merge history in the distribution database. To do this, run the following statements:
|
How to correct existing damaged identity ranges for a problematic table
After you install the cumulative update or after you use the method that is described in the workaround section, an existing damaged identity range in a table is not corrected. You will still receive the "548" error message if you try to insert data into the table and synchronize data on a subscriber. Therefore, you must manually correct the damaged identity ranges for the table. To do this, follow these steps.Note These steps involve manually overriding the current identity seed value for the table to correctly reseed the identity value at the publisher. In the damaged state, the current identity value is smaller than the first identity range in the merge replication identity range check constraint. The steps manually raise the identity value to fall inside the identity range that is defined by the merge replication identity range check constraint. These steps assume that identities are configured in an ascending manner and that the identity increment is configured to increase by a value of 1.
1. | Confirm that the identity increment value is 1 and that the identity proceeds in ascending manner. You can obtain the identity increment value by running the following statement on the publisher:
|
||||
2. | Run the following statement on the publisher to find the current identity value on the problematic identity column:
After you receive the result, note the current identity value value for comparison in the later steps. Notice that the current column value valye may be either larger or smaller than the current identity value value.If the current column value value is larger than the current identity value value, the column value may have originated at other replications in the topology and merged successfully with the publisher replication. If the current column value value is smaller than the current identity value value, the values may have been inserted on the publisher at a earlier time by using the SET IDENTITY_INSERT ON statement before the merge replication configuration. |
||||
3. | Run the following statements on the publisher to determine the current identity ranges of the identity range check constraint for the problematic table:
After you receive the result, note the value of the constraint_keys column of the record where the value of the constraint_name column is "repl_identity_range_GUID". The GUID value corresponds to the value of the artid column for the article in the sysmergearticles system table. To obtain the GUID, run the following statement:
The identity range check constraint spans two separate ranges. The two sets of ranges do not have to be contiguous. For example, the value of the constraint_keys column can be as follows:
([ColumnName]>(1001) AND [ColumnName]<=(2001)
Note This article uses this example to present code in the rest of steps.OR [ColumnName] > (9001) AND [ColumnName]<=(10001)) In this example, the ranges each span 1,000 values. 1,000 is the default range size. However, you can change the identity range size by using one of the following methods:
|
||||
4. | If you experience the problem that is described in the "Symptoms" section, the current identity value that you noted in step 2 should be smaller than the lower bound of the first identity range of the identity range check constraint that you noted in step 3. If the current identity value in step 2 is larger than the upper bound of the second identity range of the identity range check constraint, resolve the problem by using the method that is recommended in the error message. Therefore, you should run the sp_adjustpublisheridentityrange stored procedure on the publisher. For more information about the sp_adjustpublisheridentityrange stored procedure, visit the following Microsoft Developer Network (MSDN) Web site: http://msdn.microsoft.com/en-us/library/ms181527.aspx (http://msdn.microsoft.com/en-us/library/ms181527.aspx)
|
||||
5. | Run the following statement to determine whether any rows are in the current identity ranges of the identity range check constraint:
Notes
|
||||
6. | Manually reseed the current identity for the problematic table to fall inside a valid range. Reseed the current identity to the lowest value of the current identity ranges plus 1. For example, if the lowest value of the current identity ranges is 1001, the first possible in-range value is 1002 because the low end of the range of the identity range check constraint uses the greater than sign (>). To do this, run the following statement on the publisher, and then go to step 8:
|
||||
7. | Manually reseed the current identity for the problematic table to fall inside a valid range. Assume that the identity increment is 1. Reseed the current identity to the value that you noted in step 5, and then add 1. For example, if the value that you noted in step 5 is 1507, reseed the current identity to 1508. To do this, run the following statement on the publisher:
|
||||
8. | Perform a test to determine whether new rows can be inserted into the table in the publisher database without error 548 occurring. |
REFERENCES
For more information about the list of builds that are available after SQL Server Service Pack 2, click the following article number to view the article in the Microsoft Knowledge Base:
For more information about the Incremental Servicing Model for SQL Server, click the following article number to view the article in the Microsoft Knowledge Base:
For more information about how to obtain SQL Server 2005 Service Pack 2, click the following article number to view the article in the Microsoft Knowledge Base:
For more information about the new features and the improvements in SQL Server 2005 Service Pack 2, visit the following Microsoft Web site:
For more information about the naming schema for SQL Server updates, click the following article number to view the article in the Microsoft Knowledge Base:
For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:
이 글은 스프링노트에서 작성되었습니다.
'Replication' 카테고리의 다른 글
복제::LOB DataType 제한 (0) | 2010.06.04 |
---|---|
복제::#5 구현&삭제 스크립트 (0) | 2010.06.04 |
복제::스냅숏 DB를 사용한 게시 초기화 (0) | 2010.06.04 |
복제::지연된 명령어 확인 (0) | 2010.04.13 |
백업 DB에서 최근 백업정보
- DBA는 백업은 중요한 일중에 하나이다. 모든 장비를 확인해 가면서 백업 성공/실패를 확인할 수 없으므로 마지막으로 백업된 날짜를 확인하여 메일로 공지되는것이 좋은 방법이다.
- 아래 쿼리는 그 내용이며 위 쿼리와 조합을 해서 백업보고를 받게 할 것이다.
- 해당 보고는 DTS 패키지나 SSIS를 사용해서 처리하거나 JOB으로 장비별로 OSQL을 접속해서 처리하도록 해도 된다. (링크드 서버를 사용하지 않기 위햬)
- select max(isnull(datediff(dd,b.backup_start_date,getdate()),0)) as 'Number of Days since last backup',
b.type as 'Backup type (D-database,L-log)', b.backup_size, d.name as database_name
from master..sysdatabases d with (nolock)
left join msdb..backupset b with (nolock) on d.name = b.database_name
and b.backup_start_date = (select max(backup_start_date)
from msdb..backupset b2
where b.database_name = b2.database_name
and b2.type = 'D')
where d.name != 'tempdb'
group by d.name, b.type, b.backup_size
union all
select max(isnull(datediff(dd,b.backup_start_date,getdate()),0))
as 'Number of Days since last backup',
b.type as 'Backup type (D-database,L-log)', b.backup_size, d.name
as database_name
from master..sysdatabases d with (nolock)
join msdb..backupset b with (nolock)
on d.name = b.database_name
and b.backup_start_date = (select max(backup_start_date)
from msdb..backupset b2
where b.database_name = b2.database_name
and b2.type = 'L')
group by d.name, b.type, b.backup_size
order by d.name,b.type -- optional - ================================================
다른 방법 - ================================================
SELECT
cast(database_name AS varchar(30)) AS [DBName],
cast(user_name AS varchar(30)) AS [UserName],
str(cast(backup_size AS decimal(20,2)) / 1048576 ,10,2) + ' MB' AS [BackupSize],
cast(datediff(n,backup_start_date,backup_finish_date) AS varchar(5)) + ' min.' AS [Duration],
cast(datediff(dd,backup_finish_date,Getdate()) AS varchar(10)) AS [BackupAge],
convert(varchar(20),backup_finish_date) AS [FinishDate],
physical_device_name AS [Location],
mf.device_type
FROM
master..sysdatabases DB
JOIN
msdb..BACKUPSET BS
ON DB.name = BS.database_name
JOIN msdb..backupmediaset MS
ON
BS.media_set_id = MS.media_set_id
JOIN msdb..backupmediafamily MF
ON
BS.media_set_id = MF.media_set_id
JOIN
(
SELECT
max(backup_set_id) AS backup_set_id
FROM
msdb..BACKUPSET BS
JOIN msdb..backupmediaset MS
ON
BS.media_set_id = MS.media_set_id
JOIN msdb..backupmediafamily MF
ON
BS.media_set_id = MF.media_set_id
WHERE
type = 'D'
AND mf.device_type <> 7
GROUP BY database_name
) MaxBackup
ON
BS.backup_set_id = MaxBackup.backup_set_id
WHERE
type = 'D'
이 글은 스프링노트에서 작성되었습니다.
'Backup/Restory' 카테고리의 다른 글
BACKUP compression (0) | 2010.06.04 |
---|---|
Admin::Recovery Model (0) | 2010.06.04 |
All DB 백업 (0) | 2010.06.03 |
복원후에러로그내역궁금증 (0) | 2010.04.04 |