Recent comments

None


İçerik Ara











Yasal Uyarı
Bu sitede sunulan tüm bilgi ve dökümanlar Turgay Sahtiyan tarafından yazılmaktadır. Yazıların kaynak göstermek şartıyla kullanılması serbesttir.

© Copyright 2009-2013
Takvim
<<  Ekim 2017  >>
PaSaÇaPeCuCuPa
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
Keywords

SQL Server’da bir tabloya kolon eklendiğinde, bu tabloya “Select *” şeklinde erişen view’lerde, eklenen kolon otomatik olarak gösterilmez. Bunun nedeni SQL Server’ın view’den dönecek kolon bilgilerini metadata tablolarında saklamasıdır. Bu duruma “Persistent Metadata” denir.

[more]

Ne demek istediğimi bir örnek ile daha detaylı anlatmaya çalışayım.

Aşağıdaki script ile 3 kolondan oluşan bir tablo create edip, daha sonra bu tabloyu bir view’ın içerisinde “select *” şeklinde kullanıyorum.

create table tbl_Sample(a int, b int,c int)
go

create view v_1
as
	select * from tbl_Sample
go

Daha sonra ilgili tabloya aşağıdaki şekilde yeni bir kolon ekliyorum.

alter table tbl_Sample add d int
go

Bu işlemden sonra tabloya select çektiğimde 4 kolon görürken, view’i sorguladığım da 3 kolon görüyorum.

select * from tbl_Sample

select * from v_1

image

Bunun nedeni giriş paragrafında da belirttiğim gibi view’den dönecek kolonların metadata tablolarında saklanıyor olması. Bu kolon bilgilerine aşağıdaki kod ile erişebiliriz.

select * from sys.columns
where object_name(object_id) = 'v_1'

image

Peki view’in yeni eklenen bu kolonu görmesi için ne yapabiliriz. Elimizde 3 seçenek var.

  1. View’i drop-create etmek. Bu yöntem view üzerindeki permission’ları kaybetme durumundan dolayı tavsiye etmediğim yöntemdir.
  2. View’i alter etmek. View alter edildiğinde artık eklenen yeni kolon view sorgusu sonucu gelecektir.
  3. sp_refreshview sistem prosedürü ile view’in metadata bilgilerini refresh etmek. 3 yöntem arasında en tavsiye edeceğim yöntem budur.

Yukarıdaki örnekte kullandığım view’in metadata bilgilerini sp_refreshview ile güncelleyip kolonun geldiğini görelim.

exec sp_refreshview 'v_1'
go

select * from v_1

image

Yukarıdaki resimde de gördüğünüz gibi view sorgusu ile yeni eklenen kolona artık erişebiliyoruz.

Fakat bu esnada aklınıza şöyle bir soru gelebilir.

“Benim kolon eklediğim tablo belki de 100’lerce view’de kullanılıyor. Bu view’leri tek tek bulup hepsi için tek tek sp_refreshview yapmak çok zahmetli bir yöntem değil mi?”

Bu sorunuza da aşağıdaki şekilde çözüm bulabilirsiniz. Aşağıdaki sorgu ile değişiklik yaptığınız table’ı refere eden bütün view’ler için otomatik olarak sp_refresfview script’i oluşturabilirsiniz.

SELECT DISTINCT name as ViewName,'EXEC sp_refreshview ''' + name + '''' as Script
FROM sys.objects AS so 
INNER JOIN sys.sql_expression_dependencies AS sed 
    ON so.object_id = sed.referencing_id 
WHERE so.type = 'V' AND sed.referenced_id = OBJECT_ID('dbo.tbl_Sample');

image

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Bu makalemde, özellikle DWH sistemlerde bulunan, bol join ya da hesaplama içeren, çok fazla kayıt döndüren sorgularda ciddi performans artışı sağlayan Indexed View’leri inceliyor olacağız.

[more]

Indexed View Nedir?

Klasik View’leri hepimiz biliyoruz. Bu View’lerde dönecek kayıt seti herhangi bir şekilde veritabanında tutulmaz ve View her çalıştığında ilgili tablolardan getirilir. View’den eğer çok fazla kayıt dönüyorsa ve ayrıca bu kayıtlarda join ve hesaplamla işlemleri bolca yapılıyorsa çoğu durumda sonucun gelmesi oldukça fazla zaman alabilir.

Yukarıda ki örneğe benzer View’lerde performans artışı için View üzerine Unique Clustered Index tanımlanabilir. Index tanımlandığında artık View’den dönecek kayıt seti veritabanında saklanıyor olacaktır. Dolayısıyla karışık sorgularda her defasında hesaplama yapılmayacak, kayıtlar veritabanında saklandığı yerden hızlı bir şekilde getirilecektir.

View’lere Index tanımlamanın bir diğer artısı, sorguda ilgili view kullanılmasa bile eğer sorgunun tamamı ya da bir kısmı view tarafından karşılanıyorsa Index’in kullanılıyor olmasıdır. Yani view üzerine tanımlanan Index’in kullanılması için View’in sorguda kullanılması şart değildir.

Indexed view SQL Server’ın tüm versiyonlarında bulunmaktadır. Fakat bir önceki paragrafta bahsettiğim özellik, yani View kullanılmadan Index’in kullanılması özelliği sadece Enterprise versiyonunda bulunmaktadır.

Hangi Sistemler İçin Uygundur? OLTP - OLAP

View üzerine Index tanımlandığında dönecek kayıt seti veritabanında saklandığı için, çok fazla update ya da insert gören tablolardan oluşan View’lere Index tanımlanması pek mantıklı değildir. Çünkü tablolarda oluşacak DML işlemleri view’lerde de yapılmak durumunda kalınacaktır. Bu da DML işlemlerinin performansını etkileyecektir.

OLAP sistemleri Indexed View kullanımı için çok iyi bir alandır. Olap sistemlerinde tablolar belirli bir zamanda (her gece beslenen DWH sistemleri gibi) DML işlemi görür ve View’ler çok fazla sayıda sorgulanır. O yüzden bu tarz sistemlerde Indexed View kullanımı mantıklı olmaktadır.

Ayrıca veritabanları beslemesinden önce Indexed View’ler kapatılabilir ve DML işlemleri tamamlandıktan sonra Indexed View’ler tekrar oluşturabilir. Bu şekilde veri beslemesi aşamasında da performans sıkıntısı ortadan kaldırabilir.

Indexed View Oluşturmanın Ön Şartları

Bir View üzerine Clustered Index tanımlamadan önce bazı ön şartların sağlanmış olması gerekmektedir. Bu ön şartlardan bazıları aşağıdaki gibidir:

  • İlgili View’in içinde başka bir View kullanılamaz.
  • View’in içinde kullanılan tüm tablolar View ile aynı veritabanında ve aynı schema sahibine ait olmak zorundadır.
  • View SchemaBinding opsiyonu ile oluşturulmak zorundadır.
  • View içinde kullanılan UDF (User Defined Functions) ‘larda SchemaBinding opsiyonu ile oluşturulmuş olmalıdır.
  • View içinde kullanılan tablo ve UDF’ler SchemaName+ObjectName şeklinde kullanılmalıdır. Örneğin Person.Address gibi.
  • View’de hesaplama fonksiyonu kullanıldı ise select kısmında COUNT_BIG(*) kullanılması zorunludur.
  • Ayrıca select kısmı için aşağıdaki engeller mevcuttur.
    • Select * şeklinde bir kullanıma izin verilmez. Kolon adları belirtilmek zorundadır.
    • Aynı kolon adı 1 den fazla kullanılamaz.(“Select col1 as a, col1 as b from tbl1” gibi)
    • CTE (Common Table Expression) kullanımına izin verilmez.
    • TOP ve Order By kullanılamaz.
    • Count kullanılamaz. Count yerine Count_Big kullanılmalıdır.

Ön şartların tamamına aşağıdaki BOL dokümanından erişebilirsiniz.

http://msdn.microsoft.com/en-us/library/ms191432.aspx

Indexed View’in Performansa Etkisi

Indexed View’ın performansa olan etkisini analiz etmek aşağıdaki örnek sorguyu kullanacağım.

SELECT TOP 5 ProductID, 
	Sum(UnitPrice*OrderQty) as SumUnitPrice,
	Sum(UnitPrice*OrderQty*UnitPriceDiscount) AS SumDiscountPrice
FROM Sales.SalesOrderDetail
GROUP BY ProductID
ORDER BY SumDiscountPrice DESC

 

Bu sorgu için bir Indexed View oluşturacağız. Daha sonra Indexed View’den önceki performansı ile karşılaştıracağız.

İlk olarak Indexed view oluşturmadan yukarıdaki sorgunun Query Planını inceleyelim.

1

Where bloğu kullanmadığım için Clustered Index Scan yapıldı. Ayrıca hesaplama fonksiyonu (sum) kullandığım için Hash Match yapıldı ki bu işlemin bana maliyeti %35.

Şimdi bu sorgu için bir View oluşturup bu View içinde bir Unique Clustered Index oluşturuyorum.

IF OBJECT_ID ('Sales.vSales', 'view') IS NOT NULL
	DROP VIEW Sales.vSales ;
GO

CREATE VIEW Sales.vSales
	WITH SCHEMABINDING -- Indexed View tanımlamak için şart
AS	
	SELECT ProductID,
	    Sum(UnitPrice*OrderQty) as SumUnitPrice,
		Sum(UnitPrice*OrderQty*UnitPriceDiscount) AS SumDiscountPrice,
		COUNT_BIG(*) as TotalSales --Group By kullanıldığında mecburi
	FROM Sales.SalesOrderDetail 
	GROUP BY ProductID
GO
--View üzerine Index tanımlıyoruz.
CREATE UNIQUE CLUSTERED INDEX VI_1
	ON Sales.vSales (ProductId)
GO

 

Şimdi 2 sorguyu beraber çalıştıracağım. IO değerlerini görmek için SET STATISTICS IO ON ile IO istatistiğini de aktif hale getiriyorum. Ayrıca ilk sorgumda View’in Index’i değil de Clustered Index kullanılması için Clustered Index’i force ediyorum.

SET STATISTICS IO ON
GO

--Clustered Index kullanılacak.
SELECT TOP 5 ProductID, 
	Sum(UnitPrice*OrderQty) as SumUnitPrice,
	Sum(UnitPrice*OrderQty*UnitPriceDiscount) AS SumDiscountPrice
FROM Sales.SalesOrderDetail WITH(INDEX(0))
GROUP BY ProductID
ORDER BY SumDiscountPrice DESC

--Indexed View kullanılacak.
SELECT TOP 5 ProductID, 
	Sum(UnitPrice*OrderQty) as SumUnitPrice,
	Sum(UnitPrice*OrderQty*UnitPriceDiscount) AS SumDiscountPrice
FROM Sales.SalesOrderDetail
GROUP BY ProductID
ORDER BY SumDiscountPrice DESC

 

İlk olarak Query Planlara bakalım.

2

İlk dikkatinizi çekmek istediğim nokta yukarıdaki sorgularda View’in adını kullanmıyor olmama rağmen 2.sorguda View üzerine tanımladığım Index otomatik olarak kullanıldı. Giriş bölümünde bahsettiğim durum yani Enterprise versiyonun bir özelliği bu.

Şimdi sorguların masraflarına bakalım. Indexed View tanımlanmadan önceki durum tanımlandıktan sonraki duruma oranla 99 kat daha performansız. Bunun nedeni Indexed View kullanarak hem daha az IO yapmış olmam hem de Group By’dan kaynaklanan Hash Match’ten kurtulmuş olmam.

Peki IO değerlerimiz nasıl?

3

İlk sorgum 1240 IO yaparken 2. Sorgum sadece 4 IO yaparak işlemi tamamlamış oldu.

Indexed View’lerde normal View’lerden farklı olarak dönecek kayıt setleri veritabanında saklanır dedik. Normal bir Clustered Index’in page’lerine bakar gibi Indexed View’in Clustered Index Page’lerine bakabilirim.

--Index'in page'leri
DBCC IND('AdventureWorks','Sales.vSales',1)

 

4

NonLeaf Level Page örneği

DBCC Page('AdventureWorks',1,8207,3)

 

5

Leaf Level Page örneği

DBCC TRACEON(3604)
GO
DBCC Page('AdventureWorks',1,8204,3)

 

6

Sonuç

Indexed View’lerde klasik View’lerden farklı olarak dönecek kayıt setleri veritabanında saklanırlar. Bu özelliklerinden dolayı çok fazla hit alan ve bol join ya da hesaplama içeren View’lerde Index kullanmak performans açısından oldukça avantaj sağlamaktadır. Tabloda yapılacak DML işlemleri ilgili View’i de etkileyeceğinden dolayı OLTP sistemlerden ziyade OLAP sistemlerinde kullanılmaları daha mantıklıdır.

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Bildiğiniz gibi LinkedServer tanımlayarak A server’ı üzerinden B Server’ında select,update gibi işlemleri yapabilmemiz mümkün.

Bugün anlatacağım OpenDataSource komutu ile linked server’a gerek kalmadan bu işlemleri nasıl yapabileceğimizi görüyor olacağız.

[more]

OpenDataSource kullanılabilmesi için sorguyu çalıştıran server’da Ad Hoc Distributed Queries özelliğinin enable edilmesi gerekmektedir.

Aksi halde şöyle bir hata alınır.

Msg 15281, Level 16, State 1, Line 1
SQL Server blocked access to STATEMENT 'OpenRowset/OpenDatasource' of component 'Ad Hoc Distributed Queries' because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of 'Ad Hoc Distributed Queries' by using sp_configure. For more information about enabling 'Ad Hoc Distributed Queries', see "Surface Area Configuration" in SQL Server Books Online.

Ad Hoc Distributed Queries özelliğini aktif etmek için sorguyu çalıştıran server’da şu script’i çalıştırabilirsiniz.

exec sp_configure 'show advanced options',1
ReConfigure with override
exec sp_configure 'Ad Hoc Distributed Queries',1
ReConfigure with override
exec sp_configure 'show advanced options',0
ReConfigure with override

Şimdi kullanıma bakalım.

Örneğin B server’ında bulunan bir tabloya select çekmek istiyorsunuz. Bunu OpenDataSource ile yapabilmek için önce B server’ında bulunan bu tabloya select çekme yetkisine sahip bir kullanıcı tanımlıyoruz. Daha sonrada bu kullanıcıyı kullanarak A server’ında şöyle bir view create ederek B server’ında bulunan bu tablonun A server’ından select çekilebilmesini sağlıyoruz.

A server’ında create edilecek view;

create view myView
with encryption
as
SELECT *
FROM OPENDATASOURCE('SQLNCLI','Data Source=ServerB;User ID=LoginName;Password=password'
		    ).AdventureWorks.Person.Address

 

Gördüğünüz gibi view create’in de with encryption keyword’unu kullandık. Bunun sebebi de tanımlamış olduğumuz kullanıcının kullanıcı adı ve şifre bilgilerini göstermek istemememiz.

Şimdi update işlemini nasıl yapabiliriz diye bakalım.

Bunun için gene encrypted olarak bir Stored Procedure (SP) create edeceğiz.

create proc sp_UpdPersonAddress
	@AddressID int,
	@PostalCode nvarchar(15)
with encryption
as
UPDATE OPENDATASOURCE('SQLNCLI','Data Source=ServerB;User ID=LoginName;Password=password'
		   ).AdventureWorks.Person.Address
SET PostalCode = @PostalCode
where AddressID=@AddressID

 

Bu update SP’si vasıtasıyla B Server’ında bulunan Person.Address tablosunun PostaCode kolonunu A server’ı üzerinden update edebiliriz.

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Bugün size bir çoğumuzun bilip hali hazırda kullanmakta olduğunu düşündüğüm bir konudan bahsetmek istiyorum. Belki hala bu özelliği kullanmayan vardır diyerek konuya giriyorum.

Bugünkü konumuz SQL Server Management Studio Object Explorer da bulunan filter özelliği.

[more]

Object Explorer filter özelliği, DB objeleri üzerinde çalışırken objeleri daha rahat bulmaya yarayan bir Management Studio özelliğidir.

Örneğin bir production DB nizde 10 bin den fazla table var ve siz table listesinden bir table a erişmek istiyorsunuz.

Zaten hali hazırda bu listeyi görüntüleyebilmek bile her makinanın harcı değilken birde bu listeden table ı bulmaya çalıştığınızı düşünün.

image

Object Explorer filter özelliği ile table listesinde ada yada schema adına göre filtreleme yaparak sorgu sonucunu kısaltıp erişmek istediğiniz objeye daha hızlı erişebilirsiniz.

Örneğin AdventureWorks DB sinde Production.Location tablo suna filter özelliği ile hızlıca erişmek istiyorum.

Bunun için Object Explorer da Tables node unda sağ tuşa tıklayıp Filter >> Filter Settings kısmına geçiyoruz.

image

Gelen ekranda aşağıdaki bilgiler ile arama yada filtreleme yapabiliyoruz.

  • Name – Aranan objenin adına göre filtreleme. Equal(Eşit), Contains(İçeren) yada Does Not Contain (İçermeyen) parametreleri ile sorgulama yapılabilmekte.
  • Schema – Aranan objenin schema adına göre filtreleme. Equal(Eşit), Contains(İçeren) yada Does Not Contain (İçermeyen) parametreleri ile sorgulama yapılabilmekte.
  • Owner – Aranan objenin owner ına göre filtreleme. Equal(Eşit) yada Does Not Contain (İçermeyen) parametreleri ile sorgulama yapılabilmekte.
  • Creation Date – Arana objenin oluşturulma tarihine göre filtreleme.

Biz örneğimizde Production.Location table ını arıyoruz. Bunun için filter ekranını aşağıdaki gibi dolduruyoruz.

image

Daha sonra Ok e bastığımızda table kısmını filterelemiş ve obje mize eriştiğimizi göreceğiz.

image

Yapılmış olan filtreyi Sağ tık ta açılan pencereden Filter >> Remove Filter dan kaldırabiliriz.

image

Basit ama önemli bir upucu olduğunu düşünüyorum.

Bu tarz filtreleme işlemlerinin Table, View, Stored Procedure, Function gibi objelerin tamamında uygulanabildiğini not düşerek yazıma son veriyorum.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Yazılım geliştiricilerin en büyük sıkıntılarından biri geliştirdikleri kodların başkaları tarafından çalınma riskidir. Execute file lar ile bu çalınma riski büyük ölçüde azaltılıyorken .Net yeni mimari yapısından kaynaklanan durum gereği .Net executable file ları bildiğiniz üzere reverse engineering yapılabilmektedir. Gerçi bu durumada önlem olarak obfuscator programları var ki bu konu başlı başına bir konu ve daha önce bloğumuzda işlenmiş durumda.

Peki ya Database Devolopment ? Geliştirdiğimiz SP, Function ve trigger ları müşteriye deploy etmemiz gerektiğinde kodlarıyla beraber apaçık şekilde mi vereceğiz. Ya da kendi firmamızda yazdığımız kodların gözükmesini istemiyorsak.

İşte bu tarz bir istek için SQL Server bize WITH Encryption key word unu sunmakta. Bu parametre ile SP, View, Function ve Trigger ları şifrelemek mümkün. 

WITH Encryption ile SP,View,Function ve Trigger ları Şifrelemek


4 obje içinde şifreleme tekniği aynı olduğu için ben sadece view i anlatacağım. Diğerlerinde aynı kod yapısı kullanılabilir.

Ufak bir view i WITH Encryption parametresi ile yazalım ve neler değiştiğini görelim.

use AdventureWorks2008
GO
CREATE VIEW VEncSample WITH ENCRYPTION
AS
  Select FirstName,LastName from Person.Person

 

View e sorgu çekmeyi deneyelim.

select * from VEncSample

 

Gördüğünüz gibi sorgu sonucunun gelme kısmında herhangi bir değişiklik yok.

Şimdi view i modify etmeye çalışalım bunun için AdventureWorks2008 >> Views kısmından view i bulalım.

view1

Burada ilk dikkatinizi çekmek istediğim konu VEncSample view inin yanındaki kilit işareti. Bu işaret bu view in encrypted olduğunu belirtmekte.

View e sağ tıkladığımızda Design in disable olduğunu göreceksiniz. Bununda sebebi encrypted olması. Dolayısıyla view i modify edemiyoruz.

view2

Peki birde view in Script ini oluşturmaya çalışalım. Bu seferde aşağıdaki gibi bir hata ile karşı karşıya kalıyoruz.

Property TextHeader is not available for View '[dbo].[VEncSample]'. This property may not exist for this object, or may not be retrievable due to insufficient access rights.  The text is encrypted. (Microsoft.SqlServer.Smo)

view3


Gördüğünüz gibi view in içeriğini görüntüleyemiyoruz.

Son bir not. Şifrelediğiniz obje lerin kodlarını kaybetmemek için script lerini açık bir halde yedeklemenizde fayda var.


İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


http://www.turgaysahtiyan.com/post/SQL-Server-e28093-SP%28Stored-Procedure%29-lere-Topluca-Yetki-Verme.aspx adresindeki yazımda Stored Procedure lere topluca nasıl yetki verilebileceğini anlatmıştım. Şimdi ise geçenlerde yazdığım bir başka SP den bahsedeğim. Bu SP ile sadece SP lere değil server da ki tüm objelere (table,function,view vs) topluca yetki verebilirsiniz.

SP şu şekilde.

CREATE PROC GivePermissionForAllObjects
	@UserName varchar(max) = '' --Yetki verilmek istenen user ya da role
	,@Databases varchar(Max) = '' --Yetki verilmek istenen DB ya da DB ler, Boş bırakılırsa bütün DB ler
	,@GrantDeny varchar(Max) = 'DENY' --GRANT, DENY, REVOKE
	,@PermissionType varchar(Max) = 'EXECUTE' --Alter, Execute, View Definition vs.
	,@ObjectType varchar(2)='' --SP,View,Function vs.
AS
if (isnull(@ObjectType,'')='') or (isnull(@ObjectType,'')='?') begin
print '
--Object Types
--FN	SQL_SCALAR_FUNCTION
--C 	CHECK_CONSTRAINT
--UQ	UNIQUE_CONSTRAINT
--SQ	SERVICE_QUEUE
--U 	USER_TABLE
--D 	DEFAULT_CONSTRAINT
--PK	PRIMARY_KEY_CONSTRAINT
--V 	VIEW
--S 	SYSTEM_TABLE
--IT	INTERNAL_TABLE
--P 	SQL_STORED_PROCEDURE
--TF	SQL_TABLE_VALUED_FUNCTION
--TR	SQL_TRIGGER
--PC	CLR_STORED_PROCEDURE
--
'
Return
end
SET NOCOUNT ON
--variables
declare @DatabasesTmp varchar(max)=@Databases
declare @DBName sysname,@ProcName sysname,@SchemaName sysname
declare @sql varchar(max)
Declare @Tbl_DB Table(DB varchar(Max))
Create Table ##Prodecures(DBName sysname, ProcName sysname, SchemaName sysname)
--

--Split Databases
if @DatabasesTmp<>'' begin
	while @DatabasesTmp <> '' begin
		if CHARINDEX(',',@DatabasesTmp)>0 begin
			insert @Tbl_DB select SUBSTRING(@DatabasesTmp,1,CHARINDEX(',',@DatabasesTmp)-1)
			set @DatabasesTmp = SUBSTRING(@DatabasesTmp,CHARINDEX(',',@DatabasesTmp)+1,LEN(@DatabasesTmp))
		end else begin
			insert @Tbl_DB select @DatabasesTmp
			set @DatabasesTmp = ''
		end
	end
end else begin
	insert @Tbl_DB select name from sys.databases where database_id>4
end
--

--code
declare CursorX cursor for 
select DB from @Tbl_DB
open Cursorx
fetch from Cursorx into @DBName
while @@FETCH_STATUS=0
begin
	set @sql = 'Use ' +@DBName + '; '+CHAR(10)+'
		insert ##Prodecures
		select '''+@DBName+''',name,SCHEMA_NAME(schema_id) from sys.objects where type='''+@ObjectType+''' '
	exec(@sql)
	fetch next from Cursorx into @DBName	
end
close Cursorx
deallocate Cursorx

declare CursorY cursor for 
select DBName,ProcName,SchemaName from ##Prodecures
open CursorY
fetch from CursorY into @DBName,@ProcName,@SchemaName
while @@FETCH_STATUS=0
begin
	set @sql = 'use ['+ @DBName + ']; ' +
		@GrantDeny+' '+@PermissionType+' ON ['+@SchemaName+'].['+@ProcName+'] TO ['+@UserName+'] AS [dbo]; '
	exec(@sql)
  fetch next from CursorY into @DBName, @ProcName, @SchemaName
end
close CursorY
deallocate CursorY

Drop Table ##Prodecures

SET NOCOUNT OFF
--code

 

Object Type için kullanılabilecek parametreler aşağıdaki gibidir.

FN SQL_SCALAR_FUNCTION
C CHECK_CONSTRAINT
UQ UNIQUE_CONSTRAINT
SQ SERVICE_QUEUE
U USER_TABLE
D DEFAULT_CONSTRAINT
PK PRIMARY_KEY_CONSTRAINT
V VIEW
S SYSTEM_TABLE
IT INTERNAL_TABLE
P SQL_STORED_PROCEDURE
TF SQL_TABLE_VALUED_FUNCTION
TR SQL_TRIGGER
PC CLR_STORED_PROCEDURE

 

Bir kaç örnek vermek gerekirse;

turgay user ına bütün AdventureWorks ve AdventureWorks2008 DB lerinde ki bütün table lar için SELECT yetkisi vermek.

exec GivePermissionForAllObjects 'turgay','AdventureWorks,AdventureWorks2008','GRANT','SELECT','U'

 

turgay user ıne bütün DB lerde ki Stored Procedure ler için EXECUTE yetkisi vermek.

exec GivePermissionForAllObjects 'turgay','','GRANT','EXECUTE','P'

 

turgay user ına bütün DB lerde verilmiş View SELECT hakkını geri almak. (REVOKE)

exec GivePermissionForAllObjects 'turgay','','REVOKE','SELECT','V'

 

turgay user ı bütün DB lerde Sistem Table larını Inherit alsa dahi SELECT çekemesin

exec GivePermissionForAllObjects 'turgay','','DENY','SELECT','S'

 

Bu şekilde istediğiniz DB de ki objelere topluca yetki verebilir yada geri alabilirsiniz.

 

İyi çalışmalar.

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan