Listing User - Functions, SP's, Tables and Views (SQL Standard/SQL 2000/SQL 2005)
2012-12-09 14:47
555 查看
The 'SQL standard' way of doing it...
SELECT*
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='PROCEDURE'
SELECT*
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='FUNCTION'
SELECT*
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='BASE TABLE'
SELECT*
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='VIEW'
The SQL Server 2000 way of doing it...
SELECT*--
Stored Procs
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty( id,N'IsProcedure')=
1
SELECT*--
Functions
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
AND(objectproperty(
id,N'IsTableFunction')=
1
ORobjectproperty(
id,N'IsScalarFunction')=
1)
SELECT*--
User tables
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty(
id,N'IsTable')=
1
SELECT*--
Views
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty(
id,N'IsView')=
1
The SQL Server 2005 way of doing it is the same as 2000 but we use schemas more, sys.objects instead of sysobjects, oh and object_id and not id...
SELECT*--
Stored Procs
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsProcedure')=
1
SELECT*--
Functions
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
AND(objectproperty(object_id,
N'IsTableFunction')=
1
ORobjectproperty(object_id,
N'IsScalarFunction')=
1)
SELECT*--
User tables
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsTable')=
1
SELECT*--
Views
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsView')=
1
So, which one do I prefer; well its certainly not the INFORMATION_SCHEMA views because they don't scale; if you need to use this type of thing inside stored procedures and performance is a factor then use sysobjects
or sys.objects!
When you say that the INFORMATION_SCHEMA views "don't scale", are you referring to their being slow when querying against tons of objects or are you talking about using these in an application that needs to query the system objects? I've worked with both
the system tables (sys tables) and INFORMATION_SCHEMA views and this is the first I've heard of someone mentioning that the INFORMATION_SCHEMA views are poor performers. The databases that I've worked on don't have more than a max of 2,000 objects so perhaps
I'm not seeing the difference when working with a product like SAP which could have tens of thousands of objects.
I guess that, since the INFORMATION_SCHEMA views get the data I needed and performance was never really an issue for me, I've never done performance tests against whether they were faster or the INFORMATION_SCHEMA views were faster!
Okay....
I just went into SSMS and ran some quick SET STATISTICS TIME ON tests between SQL 2000 and SQL 2005 using the INFORMATION_SCHEMA.VIEWS view (not the TABLES view as you have listed above) and querying the system tables. On my laptop, the INFORMATION_SCHEMA view
queries were *marginally* faster. If you want to be picky, they were practically the same for my small test database (10GB, 500 objects) on a laptop.
Querying the system tables in SQL 2000 took 61 ms total whereas the INFORMATION_SCHEMA.VIEWS query took 47 ms.
Querying the system tables in SQL 2005 took 54 ms total whereas the INFORMATION_SCHEMA.VIEWS query took 51 ms.
What is about the INFORMATION_SCHEMA views that don't scale? I've just never heard anyone mention that before and I'd like to see what scenarios that I should/should not use them.
Thanks!
Scott Whigham
Show me the queries on INFORMATION_SCHEMA you have used and I'll show you how they don't scale.
I developed a key DB component in a enterprise knowledge management system that had dynamic schema that relied on system tables to define what objects I had available, I was very quick to ditch INFORMATION_SCHEMA.
You state stuff in milliseconds which leads me to believe you are looking at CPU stuff because STATS IO gives stuff in READS which is the important measure, anyway - please post your queries and I'll repro the scalability problem; may be I need to write a blog
entry around this - might be an idea.
My queries were your queries - I just copied and pasted the queries against sysobjects/sys.objects for views and I wrote a SELECT * FROM INFORMATION_SCHEMA.VIEWS (instead of your example using INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'VIEW')
You are correct about my looking at "CPU stuff" and I even mentioned that I turned STATISTICS TIME ON before running all queries. I ran each query multiple times also to avoid the parse/compile/bind time affecting output time. Since you mention the reads, I
ran the same queries through SET STATISTICS IO in both 2000 and 2005 for both using sysobjects/sys.objects and INFORMATION_SCHEMA.VIEWS. Interesting:
SET STATISTICS IO output for sys.objects query for Views in SQL Server 2005:
Table 'syspalnames'. Scan count 0, logical reads 26, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syssingleobjrefs'. Scan count 0, logical reads 26, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 22, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SET STATISTICS IO output for INFORMATION_SCHEMA.VIEWS query in SQL Server 2005:
Table 'sysschobjs'. Scan count 1, logical reads 22, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SET STATISTICS IO output for sysobjects query for Views in SQL Server 2000:
Table 'sysobjects'. Scan count 1, logical reads 27, physical reads 0, read-ahead reads 0.
SET STATISTICS IO output for INFORMATION_SCHEMA.VIEWS query in SQL Server 2000:
Table 'syscomments'. Scan count 45, logical reads 141, physical reads 0, read-ahead reads 0.
Table 'sysobjects'. Scan count 1, logical reads 27, physical reads 0, read-ahead reads 0.
It seems as though, for SQL 2000, the INFORMATION_SCHEMA views were worse/less scaling but in 2005, they are the better option. What do you get?
From: http://sqlblogcasts.com/blogs/tonyrogerson/archive/2006/06/29/850.aspx
The 'SQL standard' way of doing it...
SELECT*
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='PROCEDURE'
SELECT*
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='FUNCTION'
SELECT*
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='BASE TABLE'
SELECT*
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='VIEW'
The SQL Server 2000 way of doing it...
SELECT*--
Stored Procs
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty( id,N'IsProcedure')=
1
SELECT*--
Functions
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
AND(objectproperty(
id,N'IsTableFunction')=
1
ORobjectproperty(
id,N'IsScalarFunction')=
1)
SELECT*--
User tables
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty(
id,N'IsTable')=
1
SELECT*--
Views
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty(
id,N'IsView')=
1
The SQL Server 2005 way of doing it is the same as 2000 but we use schemas more, sys.objects instead of sysobjects, oh and object_id and not id...
SELECT*--
Stored Procs
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsProcedure')=
1
SELECT*--
Functions
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
AND(objectproperty(object_id,
N'IsTableFunction')=
1
ORobjectproperty(object_id,
N'IsScalarFunction')=
1)
SELECT*--
User tables
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsTable')=
1
SELECT*--
Views
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsView')=
1
So, which one do I prefer; well its certainly not the INFORMATION_SCHEMA views because they don't scale; if you need to use this type of thing inside stored procedures and performance is a factor then use sysobjects
or sys.objects!
SELECT*
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='PROCEDURE'
SELECT*
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='FUNCTION'
SELECT*
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='BASE TABLE'
SELECT*
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='VIEW'
The SQL Server 2000 way of doing it...
SELECT*--
Stored Procs
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty( id,N'IsProcedure')=
1
SELECT*--
Functions
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
AND(objectproperty(
id,N'IsTableFunction')=
1
ORobjectproperty(
id,N'IsScalarFunction')=
1)
SELECT*--
User tables
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty(
id,N'IsTable')=
1
SELECT*--
Views
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty(
id,N'IsView')=
1
The SQL Server 2005 way of doing it is the same as 2000 but we use schemas more, sys.objects instead of sysobjects, oh and object_id and not id...
SELECT*--
Stored Procs
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsProcedure')=
1
SELECT*--
Functions
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
AND(objectproperty(object_id,
N'IsTableFunction')=
1
ORobjectproperty(object_id,
N'IsScalarFunction')=
1)
SELECT*--
User tables
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsTable')=
1
SELECT*--
Views
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsView')=
1
So, which one do I prefer; well its certainly not the INFORMATION_SCHEMA views because they don't scale; if you need to use this type of thing inside stored procedures and performance is a factor then use sysobjects
or sys.objects!
#re: Listing User - Functions, SP's, Tables and Views (SQL Standard/SQL 2000/SQL 2005)
30 June 2006 13:05 byLearnSqlServer.comWhen you say that the INFORMATION_SCHEMA views "don't scale", are you referring to their being slow when querying against tons of objects or are you talking about using these in an application that needs to query the system objects? I've worked with both
the system tables (sys tables) and INFORMATION_SCHEMA views and this is the first I've heard of someone mentioning that the INFORMATION_SCHEMA views are poor performers. The databases that I've worked on don't have more than a max of 2,000 objects so perhaps
I'm not seeing the difference when working with a product like SAP which could have tens of thousands of objects.
I guess that, since the INFORMATION_SCHEMA views get the data I needed and performance was never really an issue for me, I've never done performance tests against whether they were faster or the INFORMATION_SCHEMA views were faster!
Okay....
I just went into SSMS and ran some quick SET STATISTICS TIME ON tests between SQL 2000 and SQL 2005 using the INFORMATION_SCHEMA.VIEWS view (not the TABLES view as you have listed above) and querying the system tables. On my laptop, the INFORMATION_SCHEMA view
queries were *marginally* faster. If you want to be picky, they were practically the same for my small test database (10GB, 500 objects) on a laptop.
Querying the system tables in SQL 2000 took 61 ms total whereas the INFORMATION_SCHEMA.VIEWS query took 47 ms.
Querying the system tables in SQL 2005 took 54 ms total whereas the INFORMATION_SCHEMA.VIEWS query took 51 ms.
What is about the INFORMATION_SCHEMA views that don't scale? I've just never heard anyone mention that before and I'd like to see what scenarios that I should/should not use them.
Thanks!
Scott Whigham
#re: Listing User - Functions, SP's, Tables and Views (SQL Standard/SQL 2000/SQL 2005)
30 June 2006 22:24 bytonyrogersonShow me the queries on INFORMATION_SCHEMA you have used and I'll show you how they don't scale.
I developed a key DB component in a enterprise knowledge management system that had dynamic schema that relied on system tables to define what objects I had available, I was very quick to ditch INFORMATION_SCHEMA.
You state stuff in milliseconds which leads me to believe you are looking at CPU stuff because STATS IO gives stuff in READS which is the important measure, anyway - please post your queries and I'll repro the scalability problem; may be I need to write a blog
entry around this - might be an idea.
#re: Listing User - Functions, SP's, Tables and Views (SQL Standard/SQL 2000/SQL 2005)
30 June 2006 23:27 byLearnSqlServer.comMy queries were your queries - I just copied and pasted the queries against sysobjects/sys.objects for views and I wrote a SELECT * FROM INFORMATION_SCHEMA.VIEWS (instead of your example using INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = 'VIEW')
You are correct about my looking at "CPU stuff" and I even mentioned that I turned STATISTICS TIME ON before running all queries. I ran each query multiple times also to avoid the parse/compile/bind time affecting output time. Since you mention the reads, I
ran the same queries through SET STATISTICS IO in both 2000 and 2005 for both using sysobjects/sys.objects and INFORMATION_SCHEMA.VIEWS. Interesting:
SET STATISTICS IO output for sys.objects query for Views in SQL Server 2005:
Table 'syspalnames'. Scan count 0, logical reads 26, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syssingleobjrefs'. Scan count 0, logical reads 26, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 1, logical reads 22, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SET STATISTICS IO output for INFORMATION_SCHEMA.VIEWS query in SQL Server 2005:
Table 'sysschobjs'. Scan count 1, logical reads 22, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SET STATISTICS IO output for sysobjects query for Views in SQL Server 2000:
Table 'sysobjects'. Scan count 1, logical reads 27, physical reads 0, read-ahead reads 0.
SET STATISTICS IO output for INFORMATION_SCHEMA.VIEWS query in SQL Server 2000:
Table 'syscomments'. Scan count 45, logical reads 141, physical reads 0, read-ahead reads 0.
Table 'sysobjects'. Scan count 1, logical reads 27, physical reads 0, read-ahead reads 0.
It seems as though, for SQL 2000, the INFORMATION_SCHEMA views were worse/less scaling but in 2005, they are the better option. What do you get?
From: http://sqlblogcasts.com/blogs/tonyrogerson/archive/2006/06/29/850.aspx
The 'SQL standard' way of doing it...
SELECT*
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='PROCEDURE'
SELECT*
FROM INFORMATION_SCHEMA.ROUTINES
WHERE ROUTINE_TYPE='FUNCTION'
SELECT*
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='BASE TABLE'
SELECT*
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_TYPE='VIEW'
The SQL Server 2000 way of doing it...
SELECT*--
Stored Procs
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty( id,N'IsProcedure')=
1
SELECT*--
Functions
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
AND(objectproperty(
id,N'IsTableFunction')=
1
ORobjectproperty(
id,N'IsScalarFunction')=
1)
SELECT*--
User tables
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty(
id,N'IsTable')=
1
SELECT*--
Views
FROMsysobjects
WHEREobjectproperty(
id,N'IsMSShipped')=
0
ANDobjectproperty(
id,N'IsView')=
1
The SQL Server 2005 way of doing it is the same as 2000 but we use schemas more, sys.objects instead of sysobjects, oh and object_id and not id...
SELECT*--
Stored Procs
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsProcedure')=
1
SELECT*--
Functions
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
AND(objectproperty(object_id,
N'IsTableFunction')=
1
ORobjectproperty(object_id,
N'IsScalarFunction')=
1)
SELECT*--
User tables
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsTable')=
1
SELECT*--
Views
FROMsys.objects
WHEREobjectproperty(object_id,
N'IsMSShipped')=
0
ANDobjectproperty(object_id,
N'IsView')=
1
So, which one do I prefer; well its certainly not the INFORMATION_SCHEMA views because they don't scale; if you need to use this type of thing inside stored procedures and performance is a factor then use sysobjects
or sys.objects!
相关文章推荐
- 未能找到存储过程 'sys.sp_addextendedproperty' SQL2005-2000
- MS SQL 2005 Express Edition 安装报错 错误为 unit 'sp_sqlagent_get_startup_info' to component 'Agent XPs'.
- SQL 2000 修改SA密码,提示错误2812,未能找到存储过程'sp_password'
- (转)A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'
- 解决SQL Server 2005 还原数据库错误:System.Data.SqlClient.SqlError: 在对 'C:/Program Files/Microsoft SQL Server/MSSQL.1/MSSQL/BusinessDB.mdf
- Wrox's SQL Server 2005 Express Edition Starter Kit
- 【SQL Server 2005 的问题】com.microsoft.sqlserver.jdbc.SQLServerException: 用户 'sa' 登录失败。该用户与可信 SQL Server 连接无关联。
- 还原数据库sql2005:'RestoreContainer::ValidateTargetForCreation' 时,操作系统返回了错误
- sql2005 'sa'用户登录失败,解决方案
- sql 2005拒绝了对对象 'xxx' (数据库 'xxx',架构 'dbo')的 SELECT 权限
- SQL2005,2008备份集中的数据库备份与现有的 'DB' 数据库不同,错误号码:3154,解决方法
- MS-sql 2005拒绝了对对象 'xxx' (数据库 'xxx',架构 'dbo')的 SELECT 权限
- Microsoft SQL Server 2005 用户'sa'登录失败(错误18456)解决方案图
- 如果使用SQLExpress 2005时要求'sp_configure 'User instances enabled''
- MS-sql 2005拒绝了对对象 ''xxx'' (数据库 ''xxx'',架构 ''dbo'')的 SELECT 权限
- MS-sql 2005拒绝了对对象 'xxx' (数据库 'xxx',架构 'dbo')的 SELECT 权限
- Visual studio 2005中调试遇到 EXECUTE permission denied on object 'sp_sdidebug', database 'master', owner 'dbo'
- (win7)SQL SERVER 2005开发版 安装错误:无法找到产品Microsoft SQL Server Native Client的安装程序包,尝试再次使用的安装包 ' Sqlncli.ms
- MS-sql 2005拒绝了对对象 ''xxx'' (数据库 ''xxx'',架构 ''dbo'')的 SELECT 权限的解决方法
- java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]对象名 'xxx' 无效