Posted by 좐군
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/336
Driver=SQLServer;Server=ServerNameHere;UID=UserIdHere;PWD=PasswordHere;Network=DBNETLIB.DLL;Encrypt=YES
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=dbNameHere;Data Source=ServerNameHere;Use Encryption for Data=True
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/241
One of the more visible changes we made in connectivity space for SQL Server 2005 was enhancing error messages reported to the user in case of connection failures. I have seen several cases over the last several months, and in this post I would like to list some of them with the root cause that caused them. The cause may not be the only one triggering a particular error message, and there may be other error messages of interest.
This is a semi-random selection from real cases I investigated. Likely I will post another batch some time in the future, and I would be happy to see replies with additional errors, particularly if the root cause is unclear.
The examples are from various client stacks – ODBC or OLEDB from SQL Native Client or from managed SqlClient.
The exact formatting of the messages will depend on the application you use. Most of the examples below used OSQL, SQLCMD, or SQL Server Management Studio.
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: TCP Provider, error: 0 - No connection could be made because the target machine actively refused it.) (Microsoft SQL Server, Error: 10061)
(a) default instance:
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 2)
(b) named instance:
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Shared Memory Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 2)
[SQL Native Client]Unable to complete login process due to delay in opening server connection
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)
Possibly:
A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
[SQL Native Client]Shared Memory Provider: Timeout error [258].
[SQL
Native Client]Login timeout expired
[SQL Native Client]Unable to complete
login process due to delay in prelogin response
[SQL Native Client]Shared Memory Provider: Could not open a connection to SQL
Server [121].
[SQL Native Client]Login timeout expired
[SQL Native
Client]An error has occurred while establishing a connection to the server. When
connecting to SQL Server 2005, this failure may be caused by the fact that under
the default settings SQL Server does not allow remote connections.
osql -E -S "<serverName> ,1433"
Login failed for user ''. The user
is not associated with a trusted SQL Server connection.
The server ERRORLOG/EventLog shows something similar to:
2005-08-11 12:46:04.29 Logon Error: 17806, Severity: 20, State:
2.
2005-08-11 12:46:04.29 Logon SSPI handshake failed with error code
0x8009030c while establishing a connection with integrated security; the
connection has been closed. [CLIENT: <IP address>]
2005-08-11
12:46:04.29 Logon Error: 18452, Severity: 14, State: 1.
2005-08-11
12:46:04.29 Logon Login failed for user ''. The user is not associated
with a trusted SQL Server connection. [CLIENT: <IP address>]
HResult 0x274C, Level 16, State 1
TCP Provider: A connection attempt
failed because the connected party did not properly respond after a period of
time, or established connection failed because connected host has failed to
respond.
Error: Microsoft SQL Native Client : An error has occurred while establishing
a connection to the server. When connecting to SQL Server 2005, this failure may
be caused by the fact that under the default settings SQL Server does not allow
remote connections..
Error: Microsoft SQL Native Client : Login timeout
expired.
HResult 0x274D, Level 16, State 1
TCP Provider: No connection could be
made because the target machine actively refused it.
Error: Microsoft SQL Native Client : An error has occurred while establishing
a connection to the server. When connecting to SQL Server 2005, this failure may
be caused by the fact that under the default settings SQL Server does not allow
remote connections..
Error: Microsoft SQL Native Client : Login timeout
expired.
출처 : http://blogs.msdn.com/sql_protocols/archive/2005/09/28/474698.aspx
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/240
| Simple search for a search term through all non-binary columns in
a single table or in every table of a database. You can search in four ways:
Contains, Starts with, Ends with and Equals. |
|
| Set all keywords to uppercase or lowercase letters. Custom
keywords can be added. Format all database objects to their proper case sensitive name. |
|
| Run selected or full window text on selected databases on the currently connected server. A new window is opened that contains one script for all databases. | |
| Find all occurrences of your search string in the execution plans
or in the results in datagrid mode. |
|
| CRUD stored procedure generation for tables based on fully customizable templates that you can change to suit your needs. |
|
| When opening a new query window you can specify a template that will be displayed. | ![]() |
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/222
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/189
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/139
Storage Top 10 Best Practices
원문 : http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/storage-top-10.mspx
Proper configuration of IO subsystems is critical to the optimal performance and operation of SQL Server systems. Below are some of the most common best practices that the SQL Server team recommends with respect to storage configuration for SQL Server.
Understand the IO characteristics of SQL Server and the specific IO requirements / characteristics of your application.
In order to be successful in designing and deploying storage for your SQL Server application, you need to have an understanding of your application’s IO characteristics and a basic understanding of SQL Server IO patterns. Performance monitor is the best place to capture this information for an existing application. Some of the questions you should ask yourself here are:
| • |
What is the read vs. write ratio of the application? | ||||||||||
| • |
What are the typical IO rates (IO per second, MB/s & size of the IOs)? Monitor the perfmon counters:
| ||||||||||
| • |
How much IO is sequential in nature, and how much IO is random in nature? Is this primarily an OLTP application or a Relational Data Warehouse application? |
To understand the core characteristics of SQL Server IO, refer to SQL Server 2000 I/O Basics.
More / faster spindles are better for performance
| • |
Ensure that you have an adequate number of spindles to support your IO requirements with an acceptable latency. |
| • |
Use filegroups for administration requirements such as backup / restore, partial database availability, etc. |
| • |
Use data files to “stripe” the database across your specific IO configuration (physical disks, LUNs, etc.). |
Try not to “over” optimize the design of the storage; simpler designs generally offer good performance and more flexibility.
| • |
Unless you understand the application very well avoid trying to over optimize the IO by selectively placing objects on separate spindles. |
| • |
Make sure to give thought to the growth strategy up front. As your data size grows, how will you manage growth of data files / LUNs / RAID groups? It is much better to design for this up front than to rebalance data files or LUN(s) later in a production deployment. |
Validate configurations prior to deployment
| • |
Do basic throughput testing of the IO subsystem prior to deploying SQL Server. Make sure these tests are able to achieve your IO requirements with an acceptable latency. SQLIO is one such tool which can be used for this. A document is included with the tool with basics of testing an IO subsystem. Download the SQLIO Disk Subsystem Benchmark Tool. |
| • |
Understand that the of purpose running the SQLIO tests is not to simulate SQL Server’s exact IO characteristics but rather to test maximum throughput achievable by the IO subsystem for common SQL Server IO types. |
| • |
IOMETER can be used as an alternative to SQLIO. |
Always place log files on RAID 1+0 (or RAID 1) disks. This provides:
| • |
better protection from hardware failure, and |
| • |
better write performance. |
Isolate log from data at the physical disk level
| • |
When this is not possible (e.g., consolidated SQL environments) consider I/O characteristics and group similar I/O characteristics (i.e. all logs) on common spindles. |
| • |
Combining heterogeneous workloads (workloads with very different IO and latency characteristics) can have negative effects on overall performance (e.g., placing Exchange and SQL data on the same physical spindles). |
Consider configuration of TEMPDB database
| • |
Make sure to move TEMPDB to adequate storage and pre-size after installing SQL Server. |
| • |
Performance may benefit if TEMPDB is placed on RAID 1+0 (dependent on TEMPDB usage). |
| • |
For the TEMPDB database, create 1 data file per CPU, as described in #8 below. |
Lining up the number of data files with CPU’s has scalability advantages for allocation intensive workloads.
| • |
It is recommended to have .25 to 1 data files (per filegroup) for each CPU on the host server. |
| • |
This is especially true for TEMPDB where the recommendation is 1 data file per CPU. |
| • |
Dual core counts as 2 CPUs; logical procs (hyperthreading) do not. |
Don’t overlook some of SQL Server basics
| • |
Data files should be of equal size – SQL Server uses a proportional fill algorithm that favors allocations in files with more free space. |
| • |
Pre-size data and log files. |
| • |
Do not rely on AUTOGROW, instead manage the growth of these files manually. You may leave AUTOGROW ON for safety reasons, but you should proactively manage the growth of the data files. |
Don’t overlook storage configuration bases
| • |
Use up-to-date HBA drivers recommended by the storage vendor |
| • |
Utilize storage vendor specific drivers from the HBA manufactures website |
| • |
Tune HBA driver settings as needed for your IO volumes. In general driver specific settings should come from the storage vendor. However we have found that Queue Depth defaults are usually not deep enough to support SQL Server IO volumes. |
| • |
Ensure that the storage array firmware is up to the latest recommended level. |
| • |
Use multipath software to achieve balancing across HBA’s and LUN’s and ensure this is functioning properly |
| • |
Simplifies configuration & offers advantages for availability |
| • |
Microsoft Multipath I/O (MPIO): Vendors build Device Specific Modules (DSM) on top of Driver Development Kit provided by Microsoft. |
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/56
원문 : http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/dw_perf_top10.mspx
Relational Data Warehouse or Reporting work loads are characterized by low volumes of very large transactions. These applications are often identified as having predominately read workloads (e.g. Decision Support, Analysis, and Reporting) with periodic feeds or batch loads. It is important to keep these characteristics in mind as we examine the significance of database design, resource utilization and system performance. The top performance bottlenecks or gotchas to avoid for Data Warehouse or Reporting applications are outlined below.
Database Design issue if….
| • |
Excessive sorting operations are performed. If you continually perform the same sorting operations over and over, you can avoid these with appropriate indexing. |
| • |
Excessive RID lookups are performed on heap tables. RID lookups mean extra IOs are required to retrieve columns that are not in the index used. This can be avoided with covered nonclustered indexes. |
| • |
Key lookups against the clustering keys look like joins however they are marked as “lookups” only in the XML showplan. These can be avoided with covered nonclustered indexes. |
| • |
A potentially beneficial index is missing on join columns resulting in HASH joins. Indexes on join columns may avoid the hash. |
CPU gotchas….
| • |
If signal waits > 25% of total waits, there is a CPU bottleneck. See sys.dm_os_wait_stats for Signal waits and Total waits. Signal waits measure the time spent in the runnable queue waiting for CPU. High signal waits indicate a CPU bottleneck. |
| • |
Avoid inappropriate plan re-use. If the query is identical, then plan re-use is a good thing. However, query parameterization that allows plan re-use is only appropriate when the result set (and intermediate work tables) are of similar size to the original plan. If result set sizes vary significantly due to differing parameter values which are common in data warehouse scenarios, plan re-use can be detrimental. Bad plans can also lead to longer running queries and IO or memory pressure. Therefore, the cost of plan generation in such cases is preferable to plan re-use. Unlike OLTP, data warehouse queries are not always identical in terms of result sets or optimal query plans. |
Memory bottleneck if….
| • |
Sudden big drop in page life expectancy. DW applications (e.g. big transactions) could experience big drops in page life expectancy. This is due to a cache flush from a big read. See Perfmon object SQL Server Buffer Manager. |
| • |
Pending memory grants. See counter Memory Grants Pending, in the Perfmon object SQL Server Memory Manager. Large memory grants can be common in Data Warehouse applications. More memory may help, otherwise the user cannot execute until memory grant occurs. |
| • |
Sudden drops or consistently low SQL Cache hit ratio. Drops or low cache hit may indicate memory pressure or missing indexes. |
IO bottleneck if…
| • |
The best metric for write performance is disk seconds per read and disk seconds per write. When the IO system is NOT under significant load, there will be no disk queuing and thus disk seconds per read or write should be as good as it gets Normally it takes 4-8 milliseconds to complete a read when there is no IO pressure. Factors for IO throughput are the number of spindles, and drive throughput such as sequential and random IOs per second (according to the vendor). As the IO requests increase, you may notice disk queuing. The effects of queuing are reflected in high disk seconds per read or write. Periodic higher values for disk seconds/read may be acceptable for many applications. For high performance OLTP applications, sophisticated SAN subsystems provide greater IO scalability and resiliency in handling spikes of IO activity. Sustained high values for disk seconds/read (>15ms) does indicate a disk bottleneck. |
| • |
High average disk seconds per write. See Perfmon Logical or Physical disk. Data Warehouse loads can be either logged with inserts, updates or deletes, or non-logged using bulk copy. Logged operations require transaction log writes. A transaction log write can be as fast as 1ms (or less) for high performance SAN environments. For many applications, a periodic spike in average disk seconds per write is acceptable considering the high cost of sophisticated SAN subsystems. However, sustained high values for average disk seconds/write is a reliable indicator of a disk bottleneck. |
| • |
Big IOs such as table and range scans may be due to missing indexes. |
Blocking bottleneck if….
| • |
Index contention. Look for high lock and latch waits in sys.dm_db_index_operational_stats. Compare with lock and latch requests. |
| • |
High average row lock or latch waits. The average row lock or latch waits are computed by dividing lock and latch wait milliseconds (ms) by lock and latch waits. The average lock wait ms computed from sys.dm_db_index_operational_stats represents the average time for each block. |
| • |
Block process report shows long blocks. See sp_configure “blocked process threshold” and Profiler “Blocked process Report” under the Errors and Warnings event. |
| • |
High number of deadlocks. See Profiler “Graphical Deadlock” under Locks event to identify the statements involved in the deadlock. |
Network bottleneck if….
| • |
High network latency coupled with an application that incurs many round trips to the database. |
| • |
Network bandwidth is used up. See counters packets/sec and current bandwidth counters in the network interface object of Performance Monitor. For TCP/IP frames actual bandwidth is computed as packets/sec * 1500 * 8 /1000000 Mbps. |
Wait statistics gotchas...
| • |
Since DataWarehouse and Reporting workloads are largely reads which are compatible with other reads, incompatible exclusive lock waits would ordinarily only come into play during batch loads or periodic feeds. If the top wait statistics are LCK_x. or PAGELATCH_EX, see “SQL Server 2005 Performance Tuning using Waits & Queues” for an explanation of sys.dm_os_wait_stats. |
| • |
There is an IO bottleneck if top wait statistics in sys.dm_os_wait_stats are related to IO such as ASYNCH_IO_COMPLETION, IO_COMPLETION, LOGMGR, WRITELOG, or PAGEIOLATCH_x. |
Indexing gotchas.
| • |
Large data warehouse can benefit from more indexes. Indexes can be used to cover queries and avoid sorting. For a data warehouse application, the cost of index overhead is only paid when data is loaded. |
| • |
Check for missing indexes in sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_groups and sys.dm_db_missing_index_details |
Watch out for fragmentation.
| • |
Excessive fragmentation is problematic for big IO operations. The Dynamic Management table valued function sys.dm_db_index_physical_stats returns the fragmentation percentage in the column avg_fragmentation_in_percent. Fragmentation should not exceed 25%. Reducing index fragmentation can benefit big range scans, common in data warehouse and Reporting scenarios |
Consider Table Partitioning for fast loads
| • |
For the large tables common in Data Warehouses, table partitioning offers important performance and manageability advantages. For example, the fastest type of load is a non-logged bulk copy. The requirements for non-logged bulk copies are that indexes must be dropped. This is not feasible on a huge billion row table UNLESS you use table partitioning. This allows one to create a staging table identical to the large table (minus indexes). A fast non-logged bulk copy is used to load data. Thereafter, indexes are added to the staging table followed by constraints. Then, a meta-data only SWITCH IN operation switches pointer locations for the populated staging table and the empty target partition of the partitioned table resulting in an fully populated partition and empty staging table. Besides a fast bulk copy, the staging table allows us to eliminate blocking in the large partitioned table during the load. For more information refer to “Loading Bulk Data into Partitioned Tables”. In addition to fast loads, partitioned tables allow fast deletes (or archiving purposes or sliding window deletes) where large logged deletes are replaced with meta-data only partition SWITCH OUT operations that switches pointer locations for the full partition (to be ‘deleted’) and an empty monolithic table. The SWITCH OUT results in an empty partition and a fully populated monolithic staging table. Thereafter the monolithic table can either be dropped or added to a partitioned archive table using SWITCH IN. Partitions also provide manageability improvements when combined with specific filegroup placement, allowing for customized backup and restore strategies. |
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/54
/*[테이블설계]*/
CREATE TABLE TreeMenu(
menu_cd int , --메뉴코드
menu_nm varchar(50) , --메뉴명
parent_cd int , --상위메뉴코드
CONSTRAINT PK_TreeMenu PRIMARY KEY (menu_cd)
)
/*[샘플데이터]*/insert into TreeMenu VALUES(1, '시작' , 0)
insert into TreeMenu VALUES(2, '프로그램' , 1)
insert into TreeMenu VALUES(3, '설정' , 1)
insert into TreeMenu VALUES(4, '보조프로그램', 2)
insert into TreeMenu VALUES(5, '제어판' , 3)
insert into TreeMenu VALUES(6, '네트워크환경', 5)
insert into TreeMenu VALUES(7, '계산기' , 4)
insert into TreeMenu VALUES(8, '그림판' , 4)
GO
/*[핵심함수 구현]*/
/***********************************************
트리구조에서
각 노드(행)의 절대위치를 Binary계산하는 함수
최대 64 Level 지원
***********************************************/
go
CREATE FUNCTION FN_TreeOrderBy(
@root int, /*루트값*/
@menu_cd int /*현재값*/
) RETURNS varbinary(256)
BEGIN
DECLARE @parent_cd int ,
@level_bin varbinary(256)
IF @menu_cd = @root
BEGIN
RETURN 0
END
select @level_bin = CAST(@menu_cd AS varbinary(4)) --값 초기화
/*루프로 menu_cd위 절대위치 계산*/
WHILE 1 = 1
BEGIN
SELECT @parent_cd = parent_cd
FROM TreeMenu WITH(NOLOCK)
WHERE menu_cd = @menu_cd
IF (@root=@parent_cd or @parent_cd=0 or @parent_cd is null)
BEGIN
BREAK
END
SELECT @menu_cd = @parent_cd
SELECT @level_bin = CAST(@parent_cd AS varbinary(4)) + @level_bin
END
RETURN @level_bin
END
go
/*[함수사용하여 조회]*/
SELECT a.* ,
dbo.FN_TreeOrderBy(1, a.menu_cd) absolute_pos
FROM TreeMenu A WITH(NOLOCK)
ORDER BY absolute_pos --계산된 열로 정열
/*
속도를 더 빨리 하기 위한 방법으로는 삭제/수정/등록시
절대위치(absolute_pos)를 계산해서 저장하는 방법입니다. 저장된 절대위치에 클러스트인덱스 설정하면 검색속도가 더욱 빠릅니다
그래도 대용량 쿼리할 때 이용하기엔 쫌 부담이 되겠네요 -ㅅ-
*/
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/39
DECLARE @cursor CURSOR , @sql NVARCHAR(1000) , @params NVARCHAR(100) DECLARE @id INT , @name NVARCHAR(200) SELECT @sql =N'SET @p_cur = CURSOR FORWARD_ONLY READ_ONLY FOR SELECT top 10 id, name FROM dbo.sysobjects WITH(NOLOCK) WHERE id < 10; OPEN @p_cur' SELECT @params = N'@p_cur CURSOR OUTPUT' EXEC sp_executesql @sql , @params , @p_cur = @cursor OUTPUT
FETCH NEXT FROM @cursor INTO @id, @name WHILE (@@FETCH_STATUS=0) BEGIN PRINT CAST(@id AS VARCHAR(10)) + ':' + @name FETCH NEXT FROM @cursor INTO @id, @name END CLOSE @cursor DEALLOCATE @cursor
Posted by 좐군
Trackback URL : http://John.tobe30.com/tc/trackback/38
- 좐군
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 |