2011. 3. 30. 10:07

Admin::Cache Flush 가 발생하는 경우


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.

2010. 6. 4. 01:18

SQL Server의 Procedure Cache 사이즈

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
2010. 6. 4. 01:12

복제::#5 구현&삭제 스크립트

 

 

복제 삭제

  1.  
  2. select replinfo,* from sysobjects where replinfo = 0 을 찾아서 입력합니다.

  3. sp_removedbreplication [ [ @dbname = ] 'dbname' ]
        [ , [ @type = ] type ]
    
  4.  
    
    1. [ @dbname=] 'dbname'
    1. 데이터베이스의 이름입니다. dbname은 sysname이며 기본값은 NULL입니다. NULL인 경우 현재 데이터베이스를 사용합니다.
    1. [ @type = ] type
    1. 데이터베이스 개체를 제거 중인 복제의 유형입니다. type은 nvarchar(5)이며 다음 값 중 하나일 수 있습니다.
    1. tran
    1. 트랜잭션 복제 게시 개체를 제거합니다.
    1. merge
    1. 병합 복제 게시 개체를 제거합니다.
    1. both(기본값)
    1. 모든 복제 게시 개체를 제거합니다.

ERROR CASE

게시& 배포자가 먼저 삭제되고 구독이 남아 있을 경우

 

 

 

 

이 글은 스프링노트에서 작성되었습니다.

'Replication' 카테고리의 다른 글

복제::숨겨진 저장프로시저 확인  (0) 2011.01.16
복제::LOB DataType 제한  (0) 2010.06.04
복제::머지복제에러  (0) 2010.06.04
복제::스냅숏 DB를 사용한 게시 초기화  (0) 2010.06.04
2010. 6. 4. 01:12

복제::머지복제에러

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"

 

 

Bug #: 50002854 (SQL Hotfix)
Microsoft distributes Microsoft SQL Server 2005 fixes as one downloadable file. Because the fixes are cumulative, each new release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2005 fix release.
On This Page

SYMPTOMS

Consider the following scenario. In SQL Server 2005, you configure a merge publication. You add a table that contains an identity column to the merge publication. Then, you insert data into the table on the publisher. You synchronize the data between the subscriber and the publisher, and then you try to insert additional data on the publisher. In this scenario, you receive the following error message on the publisher:
Msg 548, Level 16, State 2, Line 1
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.
If you try to run the sp_adjustpublisheridentityrange stored procedure on the publisher as mentioned in the error message, you still cannot resolve this problem.

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.

Back to the top

CAUSE

This problem occurs because the current identity value of the table on the publisher is not within the identity range of the identity range check constraint. This behavior occurs when multiple Merge Agents try to increase the identity range at the same time by creating the next identity range on the publisher.

Back to the top

RESOLUTION

The fix for this issue was first released in Cumulative Update 8. For more information about how to obtain this cumulative update package for SQL Server 2005 Service Pack 2, click the following article number to view the article in the Microsoft Knowledge Base:
951217 (http://kbalertz.com/Feedback.aspx?kbNumber=951217/) Cumulative update package 8 for SQL Server 2005 Service Pack 2
Note Because the builds are cumulative, each new fix release contains all the hotfixes and all the security fixes that were included with the previous SQL Server 2005 fix release. Microsoft recommends that you consider applying the most recent fix release that contains this hotfix. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
937137 (http://kbalertz.com/Feedback.aspx?kbNumber=937137/) The SQL Server 2005 builds that were released after SQL Server 2005 Service Pack 2 was released
Microsoft SQL Server 2005 hotfixes are created for specific SQL Server service packs. You must apply a SQL Server 2005 Service Pack 2 hotfix to an installation of SQL Server 2005 Service Pack 2. By default, any hotfix that is provided in a SQL Server service pack is included in the next SQL Server service pack.

Back to the top

WORKAROUND

To work around this problem, you must prevent multiple concurrent merge synchronizations. To do this, set the max_concurrent_merge property on the merge publication by running the following statement:
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.

Back to the top

STATUS

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.

Back to the top

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:
SELECT IDENT_CURRENT ('<TableName>')
To obtain the identity ranges of the identity range check constraint, run either of the following statements:
Statement 1
sp_helpconstraint '<TableName>'
Statement 2
select * from MSmerge_identity_range
where is_pub_range <>1
AND artid IN 
 (select artid from sysmergearticles where name='<TableName>')
AND subid in 
 (select subid from sysmergesubscriptions  MS
join sysmergepublications MP 
on MS.subscriber_server=MP.publisher
AND MS.db_name = MP.publisher_db
WHERE name='<PublicationName>'
)

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:
Use distribution
GO
select session_id, agent_id, B.publication, min(time) as StartTime, max(time) as EndTime
into #sessiontimes
from dbo.MSmerge_history A
join dbo.msmerge_agents B
on A.agent_id = B.id
group by session_id, agent_id, publication
order by 3 desc
GO
-- The left side result is the original session. The right side result is the overlapping session.
select A.*, B.* 
from #sessiontimes A
Join #sessiontimes B
On B.StartTime >= A.StartTime
AND B.StartTime <= A.EndTime
AND A.session_id <> B.session_id
And A.publication=B.publication
Order By A.StartTime asc
GO
drop table #sessiontimes

Back to the top

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:
SELECT IDENT_INCR( '<TableName>')
2. Run the following statement on the publisher to find the current identity value on the problematic identity column:
DBCC CHECKIDENT ('<TableName>')
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:
Use <PublishedDatabaseName>
GO
sp_helpconstraint '<TableName>'
GO

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:
select artid from sysmergearticles where name = '<TableName>'
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)
OR [ColumnName] > (9001) AND [ColumnName]<=(10001))
Note This article uses this example to present code in the rest of steps.

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:
• Specify the @pub_identity_range parameter when you run the sp_addmergearticle stored procedure.
• Change the Subscriber range size property for the article in the Article Properties dialog box.
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:
SELECT COUNT(*) FROM TableName WHERE 
([ColumnName]>(1001) AND [ColumnName]<=(2001) 
OR [ColumnName]>(9001) AND [ColumnName]<=(10001))

Notes
• If the statement returns 0, no rows are in the current identity ranges. In this case, go to step 6.
• If the statement returns a value that is larger than 0, run the following statement to obtain the maximum identity value in the current identity ranges:
SELECT MAX(ColumnName) as MaxValue FROM TableName WHERE 
([ColumnName]>(1001) AND [ColumnName]<=(2001) OR 
[ColumnName]>(9001) AND [ColumnName]<=(10001))

Note the returned value, and then go to step 7.
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:
DBCC CHECKIDENT ('TableName', RESEED, 1002)
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:
DBCC CHECKIDENT ('TableName', RESEED, 1508)
8. Perform a test to determine whether new rows can be inserted into the table in the publisher database without error 548 occurring.

Back to the top

For more information about what files are changed, and for information about any prerequisites to apply the cumulative update package that contains the hotfix that is described in this Microsoft Knowledge Base article, click the following article number to view the article in the Microsoft Knowledge Base:
951217 (http://kbalertz.com/Feedback.aspx?kbNumber=951217/) Cumulative update package 8 for SQL Server 2005 Service Pack 2

Back to the top

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:

937137 (http://kbalertz.com/Feedback.aspx?kbNumber=937137/) The SQL Server 2005 builds that were released after SQL Server 2005 Service Pack 2 was released

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:

935897 (http://kbalertz.com/Feedback.aspx?kbNumber=935897/) An Incremental Servicing Model is available from the SQL Server team to deliver hotfixes for reported problems

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:

913089 (http://kbalertz.com/Feedback.aspx?kbNumber=913089/) How to obtain the latest service pack for SQL Server 2005

For more information about the new features and the improvements in SQL Server 2005 Service Pack 2, visit the following Microsoft Web site:

http://go.microsoft.com/fwlink/?LinkId=71711 (http://go.microsoft.com/fwlink/?LinkId=71711)

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:

822499 (http://kbalertz.com/Feedback.aspx?kbNumber=822499/) New naming schema for Microsoft SQL Server software update packages

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:

824684 (http://kbalertz.com/Feedback.aspx?kbNumber=824684/) Description of the standard terminology that is used to describe Microsoft software updates

이 글은 스프링노트에서 작성되었습니다.

'Replication' 카테고리의 다른 글

복제::LOB DataType 제한  (0) 2010.06.04
복제::#5 구현&삭제 스크립트  (0) 2010.06.04
복제::스냅숏 DB를 사용한 게시 초기화  (0) 2010.06.04
복제::지연된 명령어 확인  (0) 2010.04.13
2010. 6. 3. 23:54

백업성공보고

백업 DB에서 최근  백업정보

  • DBA는 백업은 중요한 일중에 하나이다. 모든 장비를 확인해 가면서 백업 성공/실패를 확인할 수 없으므로 마지막으로 백업된 날짜를 확인하여 메일로 공지되는것이 좋은 방법이다. 
  • 아래 쿼리는 그 내용이며 위 쿼리와 조합을 해서 백업보고를 받게 할 것이다.  
  • 해당 보고는 DTS 패키지나 SSIS를 사용해서 처리하거나 JOB으로 장비별로 OSQL을 접속해서 처리하도록 해도 된다. (링크드 서버를 사용하지 않기 위햬) 
  1. 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 
  2. ================================================
    다른 방법 
  3. ================================================
    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