USE master
GO


--1. tempdb의논리파일이름확인

SELECT name, physical_name, state_desc
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb')
GO


--2. ALTER DATABASE 사용하여파일위치변경

ALTER DATABASE tempdb MODIFY FILE(NAME = tempdev, FILENAME = 'd:\mssql\tempdb.mdf')
ALTER DATABASE tempdb MODIFY FILE(NAME = templog, FILENAME = 'e:\mssql\templog.ldf')
GO


--3. Processor만큼파일분할및사이즈변경및파일사이즈, 증가옵션설정

ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', SIZE = 20480KB , FILEGROWTH = 10240KB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev2', FILENAME = N'd:\mssql\tempdev2.ndf' , SIZE = 20480KB , FILEGROWTH = 10240KB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev3', FILENAME = N'd:\mssql\tempdev3.ndf' , SIZE = 20480KB , FILEGROWTH = 10240KB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdev4', FILENAME = N'd:\mssql\tempdev4.ndf' , SIZE = 20480KB , FILEGROWTH = 10240KB )
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'templog', SIZE = 163840KB )
GO

--4.SQL Server 서비스 재시작.
 

--5.SQL Server 서비스가 시작된것을확인후 정상 이동 확인 

SELECT name, physical_name, state_desc 
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb')

참고 : http://blog.naver.com/PostView.nhn?blogId=jevida&logNo=140149742633

DBCC CHECKIDENT

-- person 스키마의 AddressType Table의 identity값 확인
USE AdventureWorks2012;  
GO  
DBCC CHECKIDENT ('Person.AddressType');  
GO  


-- Person 스키마의 AddressType Table의 identity값을 10으로 변경
-- 이후 identity값은 11을 반환
USE AdventureWorks2012;  
GO  
DBCC CHECKIDENT ('Person.AddressType', RESEED, 10);
GO


참고 : https://docs.microsoft.com/ko-kr/sql/t-sql/database-console-commands/dbcc-checkident-transact-sql?view=sql-server-2017 

 

DBCC CHECKIDENT(Transact-SQL) - SQL Server

DBCC CHECKIDENT(Transact-SQL)

docs.microsoft.com

--{SQL handle} 부분에 값을 입력하여 실행

(방법 1)
SELECT sql_handle AS Handle,
SUBSTRING(st.text, (qs.statement_start_offset/2)+1, 
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2) + 1) AS Text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
WHERE sql_handle = --{SQL Handle}

(방법2)
select * from sys.dm_exec_query_plan({SQL Handle})
select * from sys.dm_exec_query_plan(0x0600030D550343000000000000000)

참고

https://rauofthameem.wordpress.com/2012/09/14/sql-query-that-gets-sql-statement-from-sqlhandle/

https://holictoweb.tistory.com/17

원인

SQL Server Agent 서비스 제어는 SQL Server Agent Roles 권한이 부여되어 있거나 또는 sysadmin role 이 부여되어 있어야 합니다.
test_srv 계정은 SQL Sever Agent Roles 또는 sysadmin role 이 없습니다. 


해결방법

방법1. 
SSMS - Security - Logins - test_srv - User Mapping - msdb - SQLAgentUserRole 부여(필요에 따라 SQLAgentReaderRole, SQLAgentOperatorRole 부여 가능)
단, 운영체제 외부 리소스를 사용하기 위해서는 별도의 Credentials, SQL Server Proxy Accounts 를 설정할 수 있음.

test_srv 계정에 view database 권한 필요

USE [master]
GO

CREATE USER [test_srv] FOR LOGIN [test_srv]



USE [msdb]
GO

CREATE USER [test_srv] FOR LOGIN [test_srv]

ALTER ROLE [SQLAgentUserRole] ADD MEMBER [test_srv]

만약 개체 존재 여부를 먼저 체크 하는 로직을 실행 한다면 아래 권한 추가

USE [msdb]
GO
GRANT SELECT ON sysjobs TO [test_srv]
GRANT SELECT ON sysjobsteps TO [test_srv]


방법2. 
sysadmin role 부여 (권장하지 않음)


참고 : https://docs.microsoft.com/ko-kr/sql/ssms/agent/sql-server-agent-fixed-database-roles?view=sql-server-2017

 

SQL Server 에이전트 고정 데이터베이스 역할 - SQL Server Agent

SQL Server 에이전트 고정 데이터베이스 역할

docs.microsoft.com

 

https://laigo.kr/497

문제

개체의 정의가 변경된다고 해서 이 개체를 참조하는 (스키마 바인딩 되지 않은) SP, UDF, VIEW의 메타데이터가 자동으로 갱신되지는 않습니다.

해결

--SQL Server 2000
참조한 개체는 Alter를 이용해서 다시 컴파일되어야 합니다. VIEW의 경우 sp_refreshview가 존재했지만, 다른 개체는 일일히 수작업을 해야 했었죠.

--SQL Server 2005
SQL Server 2005 SP2에서 sp_refreshsqlmodule 이 처음으로 소개되었습니다. 이 system sp를 이용하면 변경된 개체를 참조하는 SP, UDF, VIEW에 대해서 한번에 변경된 메타데이터를 갱신해 줍니다. 여전히 sp_refreshview도 사용 가능합니다.

실행 예)
EXEC sys.sp_refreshsqlmodule 'dbo.to_upper';

출처
http://msdn2.microsoft.com/ko-kr/library/bb326754.aspx
https://optimizer.tistory.com/entry/SQL2k5sprefreshsqlmodule-vs-sprefreshview

[요약]

1. MySQL Connector ODBC 설치
2. ODBC 데이터 원본(64) 실행
3. 시스템 DSN에 등록
4. 시스템 DSN에 등록한 이름으로 MSSQL LinkedServer 생성
5. 접속 중 MSDASQL의 스키마 또는 카탈로그 에러시, 연결되 서버 -> 공급자 -> MSDASQL -> 속성 옵션 수정
6. 오픈 쿼리로 실행 ( select * from openquery ( 'DSN이름', 'select * from tbl_a')

 

 


[구성]

Mysql 연결 드라이버 다운

다운로드 받은 파일을 설치

드라이버 설치가 완료되면 윈도우 [서버 관리자]에서 ODBC [데이터 원본]을 실행

ODBC 데이터 원본 관리자에서 [시스템 DSN]탭을 선택하고 [추가]버튼을 클릭

[새 데이터 원본 만들기] 창이 나타나면 MySQL ODBC 5.3 드라이버를 선택

연결 속성에 각 정보를 입력

Database항목에 해당 MySQL/MariaDB의 데이터베이스 목록이 보이지 않는다면 설정이 잘못되었으니 정보를 확인하고 정확하게 입력한다.

ODBC 데이터 원본 추가작업이 완료되면 시스템 데이터 원본 목록에서 사용자가 생성한 연결 정보가 나타난다.

SQL Server의 SSMS 도구에서 [새 연결된 서버]를 실행하여 링크드서버를 등록

서버 유형은 [기타 데이터 원본]에서 공급자를 OLE DB Provider for ODBC Drivers를 선택 한다.

보안 탭에서 사용자 로그인 계정과 비밀번호를 입력

링크드서버 등록이 완료되면 SSMS에서 추가된 링크드서버를 확인


[사용]

아래 스크립트는 분산 쿼리 및 원격 저장 프로시저에 사용되는 링크드서버로그인 정보를 확인한다. 사용자가 생성한 링크드명과 리모트 로그인 정보를 확인 할 수 있다.

exec sp_helplinkedsrvlogin

 

다음 스크립트는 지정된 연결된 서버에서 테이블에 대한 정보를 반환한다.

exec sp_tables_ex 'MARIADB'

 

MySQL/MariaDB 쿼리 조회는 Openquery를 사용한다.

select * from openquery (MARIADB, 'select * from tbl_a')

 

SQL Server에서 스키마 방식으로 링크드서버 데이터를 조회하였을 때 다음과 같은 에러가 발생한다면 공급자 MSDASQL에서 공급자 옵션을 체크해야 한다.

메시지 7313, 수준 16, 상태 1, 줄 1
연결된 서버 "MARIADB"에 대한 공급자 "MSDASQL"의 스키마 또는 카탈로그를 잘못 지정했습니다.

 

스키마 방식의 데이터 조회 오류를 해결 하기 위해 링크드서버에서 공급자를 확장하면 연결 공급자 목록이 나타난다. MSDASQL을 선택하고 속성을 클릭한다.

MSDASQL 공급자 옵션 창이 나타나면 필요한 옵션을 선택한다.

스키마를 사용한 데이터 조회가 가능한 것을 확인 할 수 있다.

SELECT * FROM MARIADB...tbl_a

 

프로시저 호출의 경우 연결된 서버 속성에서 RPC 구성을 활성화해야 쿼리를 실행할 수 있다.

execute ('select * from tbl_a') at MARIADB

 

 

참고 : https://sqlmvp.tistory.com/1072?category=618825 [Data Science Lab]

확인 내용

* procedure가 올바른 plan을 선정하였는지

* cached plan 사이즈가 효율적으로 사용되고 있는지

* plan에 해당하는 query확인

 

 

Procedure query_id 및 plan_id 확인

하나의 SP에 여러 plan이 존재할수 있음 

그중 비효율적인 plan을 사용하는 경우 이슈가 발생

--'spTest_get' SP를 분석

select qsq.query_id, qp.plan_id, qst.query_sql_text, qp.query_plan 
from sys.query_store_query qsq
inner join sys.query_store_query_text qst
	on qsq.query_text_id = qst.query_text_id
inner join sys.query_store_plan qp
	on qp.query_id = qsq.query_id
where object_id = object_id('spTest_get')

/**
query_id	plan_id
5324	662
5324	782
5324	787
5324	807
5324	818

3315	663
8092	1200
8093	1201
**/

Cached plan 카운트 및 사이즈

adhoc 쿼리를 과도하게 호출 시 cached plan이 저장 가능한 공간을 초과 할 수 있음.

아래의 경우 1회만 사용되는 plan이 대부분인 케이스

1회만 사용되는 plan을 sp_executesql 형태로 변경하거나 동일 plan을 사용하도록 유도가 필요함

-- 모든 cached plan을 조회

select objtype, count(*) as cnt, sum(convert(bigint, size_in_bytes))/(1024*1024) as size_mb
from sys.dm_exec_cached_plans
--where usecounts = 1
group by objtype
order by cnt desc

/**
objtype	cnt	size_mb
Adhoc	156329	6906			<--
Prepared	3708	967
View	1285	181
Proc	215	253
**/


-- cached plan 사용 횟수가 1회 경우만 조회
select objtype, count(*) as cnt, sum(convert(bigint, size_in_bytes))/(1024*1024) as size_mb
from sys.dm_exec_cached_plans
where usecounts = 1
group by objtype
order by cnt desc

/**
objtype	cnt	size_mb
Adhoc	153763	1889			<--
Prepared	3145	242
Proc	41	19
**/

query_hash 통한 이슈 query 확인

이슈 query 확인 후 수정

-- 실행 count가 1인 경우만 조회

select query_hash, count(*) as cnt
from sys.dm_exec_query_stats
where execution_count = 1
group by query_hash
order by cnt desc

/**
query_hash	cnt
0xD1CC06V33C082806	135420      <--- 확인
0x3129830A6071HND2	2108
0x30E30C19A239CX39	218
0x690CY4EC5110G475	218
~
**/


-- 이슈 query text 확인

select top 100 st.text
from sys.dm_exec_query_stats qs
cross apply sys.dm_exec_sql_text (qs.sql_handle) as st
where qs.query_hash = 0xD1CC06V33C082806 

/**
USE master   INSERT INTO *******************
USE master   INSERT INTO *******************
**/

to Top