存档

‘SQL SERVER’ 分类的存档,文章数:35

SQL SERVER 2005 无人值守安装过程

命令：

==适用于sqlserver2005 developer

setup.exe /qb INSTANCENAME=MSSQLSERVER ADDLOCAL=SQL_Engine,Client_Components,Connectivity,SQL_Tools90  SAPWD=andkylee SQLACCOUNT="NT AUTHORITY\SYSTEM" SQLPASSWORD= AGTACCOUNT="NT AUTHORITY\SYSTEM" AGTPASSWORD= SQLBROWSERACCOUNT="NT AUTHORITY\SYSTEM"  SQLBROWSERPASSWORD= SECURITYMODE=SQL DISABLENETWORKPROTOCOLS=0 SQLCOLLATION=Chinese_PRC_CI_AS ASCOLLATION=Chinese_PRC_CI_AS

==适用于sqlserver2005 express

start /wait setup.exe /qb INSTANCENAME=MSSQLSERVER ADDLOCAL=SQL_Engine,Client_Components,Connectivity,SDK SAPWD=liuzhenfu SQLACCOUNT="NT AUTHORITY\SYSTEM" SQLPASSWORD= AGTACCOUNT="NT AUTHORITY\SYSTEM" AGTPASSWORD= SQLBROWSERACCOUNT="NT AUTHORITY\SYSTEM"  SQLBROWSERPASSWORD= SECURITYMODE=SQL DISABLENETWORKPROTOCOLS=0 SQLCOLLATION=Chinese_PRC_CI_AS ASCOLLATION=Chinese_PRC_CI_AS

阅读全文…

标签: ,

sql server 2008中的备份压缩特性

sql server 2005不支持备份压缩。很奇怪怎么不支持呢？ sybase在ASE12.x都支持备份压缩了。

自sql server 2008才开始支持备份压缩。虽然只有 SQL Server 2008 Enterprise 及更高版本支持创建压缩的备份，但从 SQL Server 2008 开始，每个版本都可以还原压缩的备份。

限制
压缩的备份具有以下限制条件：

压缩的备份和未压缩的备份不能共存于一个媒体集中。

早期版本的 SQL Server 无法读取压缩的备份。

NTbackup 无法共享包含压缩的 SQL Server 备份的磁带。

 

压缩备份的性能影响
因为相同数据的压缩的备份比未压缩备份小，所以压缩备份所需的设备 I/O 通常较少，因此通常可大大提高备份速度。

默 认情况下，压缩会显著增加 CPU 的使用，并且压缩进程所消耗的额外 CPU 可能会对并发操作产生不利影响。因此，您可能需要在会话中创建低优先级的压缩备份，其 CPU 使用率受资源调控器限制。有关详细信息，请参阅如何使用资源调控器限制备份压缩的 CPU 使用量 (Transact-SQL)。

若要很好地了解备份 I/O 的性能表现，可以通过评估以下类型的性能计数器来分别考察进入设备或来自设备的备份 I/O：

Windows I/O 性能计数器，例如物理磁盘计数器

SQLServer:Backup Device 对象的 Device Throughput Bytes/sec 计数器

SQLServer:Databases 对象的 Backup/Restore Throughput/sec 计数器

有关 Windows 计数器的信息，请参阅 Windows 帮助。有关如何使用 SQL Server 计数器的信息，请参阅使用 SQL Server 对象。

阅读全文...

标签: ,

sql server 2000 扩展盘区分配错误 error:8905 的问题解决

在用dbcc checkdb 对数据库进行检查的时候，在数据结果的头部报下面的错误：

扩展盘区 (1:9508664) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508672) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508680) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508688) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508696) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508704) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508712) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508720) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508728) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508736) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508744) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508760) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508776) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508792) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508800) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508808) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508816) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
        DBCC 语句的修复级别导致回避了此修复。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508824) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508832) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1
 扩展盘区 (1:9508840) （属于数据库 ID 7 ）在 GAM 中标记为已分配，但没有 SGAM 或 IAM 分配过该盘区。
 消息 8905 ，级别 16 ，状态 1 ，服务器 SERVER ，行 1

阅读全文...

标签: , ,

如何识别 SQL Server 的版本

 本文介绍如何识别当前的 Microsoft SQL Server 版本号和相应的产品或 Service Pack 级别。同时介绍如何识别正在使用的 SQL Server 具体版本。

如何确定正在运行的 SQL Server 2008 为哪个版本

若要确定正在运行的 SQL Server 2008 为哪个版本，请使用 SQL Server Management Studio 连接到 SQL Server 2008 ，然后运行下列 Transact-SQL 语句。

SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

运行结果如下：

  • 产品版本（例如，10.0.1600.22 ）
  • 产品级别（例如，RTM ）
  • 版本（例如， Enterprise ）

例如，运行结果可能类似于如下内容。

收起该表格展开该表格

10.0.1600.22

RTM

Enterprise Edition

下表列出了 Sqlservr.exe 版本号。

收起该表格展开该表格



版本

Sqlservr.exe


RTM

2007.100.1600.0

SQL Server 2008 Service Pack 1

2007.100.2531.0

阅读全文...

标签: ,

sql server 2000中创建索引时的填充因子fillfactor

PAD_INDEX

Specifies the space to leave open on each page (node) in the intermediate levels of the index. The PAD_INDEX option is useful only when FILLFACTOR is specified, because PAD_INDEX uses the percentage specified by FILLFACTOR. By default, SQL Server ensures that each index page has enough empty space to accommodate at least one row of the maximum size the index can have, given the set of keys on the intermediate pages. If the percentage specified for FILLFACTOR is not large enough to accommodate one row, SQL Server internally overrides the percentage to allow the minimum.

Note   The number of rows on an intermediate index page is never less than two, regardless of how low the value of

FILLFACTOR

FILLFACTOR = fillfactor

Specifies a percentage that indicates how full SQL Server should make the leaf level of each index page during index creation. When an index page fills up, SQL Server must take time to split the index page to make room for new rows, which is quite expensive. For update-intensive tables, a properly chosen FILLFACTOR value yields better update performance than an improper FILLFACTOR value. The value of the original FILLFACTOR is stored with the index in sysindexes .

When FILLFACTOR is specified, SQL Server rounds up the number of rows to be placed on each page. For example, issuing CREATE CLUSTERED INDEX ... FILLFACTOR = 33 creates a clustered index with a FILLFACTOR of 33 percent. Assume that SQL Server calculates that 5.2 rows is 33 percent of the space on a page. SQL Server rounds so that six rows are placed on each page.

Note   An explicit FILLFACTOR setting applies only when the index is first created. SQL Server does not dynamically keep the specified percentage of empty space in the pages.

User-specified FILLFACTOR values can be from 1 through 100. If no value is specified, the default is 0. When FILLFACTOR is set to 0, only the leaf pages are filled. You can change the default FILLFACTOR setting by executing sp_configure .

Use a FILLFACTOR of 100 only if no INSERT or UPDATE statements will occur, such as with a read-only table. If FILLFACTOR is 100, SQL Server creates indexes with leaf pages 100 percent full. An INSERT or UPDATE made after the creation of an index with a 100 percent FILLFACTOR causes page splits for each INSERT and possibly each UPDATE.

Smaller FILLFACTOR values, except 0, cause SQL Server to create new indexes with leaf pages that are not completely full. For example, a FILLFACTOR of 10 can be a reasonable choice when creating an index on a table known to contain a small portion of the data that it will eventually hold. Smaller FILLFACTOR values also cause each index to take more storage space.

The following table illustrates how the pages of an index are filled up if FILLFACTOR is specified.

FILLFACTOR Intermediate page Leaf page
0 percent One free entry 100 percent full
1 - 99 percent One free entry <= FILLFACTOR percent full
100 percent One free entry 100 percent full

One free entry is the space on the page that can accommodate another index entry.

Important   Creating a clustered index with a FILLFACTOR affects the amount of storage space the data occupies because SQL Server redistributes the data when it creates the clustered index.

示例：

This example uses the FILLFACTOR clause set to 100. A FILLFACTOR of 100 fills every page completely and is useful only when you know that index values in the table will never change.

SET NOCOUNT OFF
USE pubs
IF EXISTS (SELECT name FROM sysindexes
      WHERE name = 'zip_ind')
   DROP INDEX authors.zip_ind
GO

USE pubs
GO

CREATE NONCLUSTERED INDEX zip_ind
   ON authors (zip)
   WITH FILLFACTOR = 100
GO

create table 时：
[WITH FILLFACTOR = fillfactor ]

Specifies how full SQL Server should make each index page used to store the index data. User-specified fillfactor values can be from 1 through 100, with a default of 0. A lower fill factor creates the index with more space available for new index entries without having to allocate new space.

阅读全文…

标签:

sys.sysdatabases的status列的值

Status bits, some of which can be set by using ALTER DATABASE as noted:

1 = autoclose (ALTER DATABASE)

4 = select into/bulkcopy (ALTER DATABASE using SET RECOVERY)

8 = trunc. log on chkpt (ALTER DATABASE using SET RECOVERY)

16 = torn page detection (ALTER DATABASE)

32 = loading

64 = pre recovery

128 = recovering

256 = not recovered

512 = offline (ALTER DATABASE)

1024 = read only (ALTER DATABASE)

2048 = dbo use only (ALTER DATABASE using SET RESTRICTED_USER)

4096 = single user (ALTER DATABASE)

32768 = emergency mode

4194304 = autoshrink (ALTER DATABASE)

1073741824 = cleanly shutdown

Multiple bits can be ON at the same time.

status2

16384 = ANSI null default (ALTER DATABASE)

65536 = concat null yields null (ALTER DATABASE)

131072 = recursive triggers (ALTER DATABASE)

1048576 = default to local cursor (ALTER DATABASE)

8388608 = quoted identifier (ALTER DATABASE)

33554432 = cursor close on commit (ALTER DATABASE)

67108864 = ANSI nulls (ALTER DATABASE)

268435456 = ANSI warnings (ALTER DATABASE)

536870912 = full text enabled (set by using sp_fulltext_database )

阅读全文…

标签:

sql server 2000 torn_page_detection error (error 823)

在sql server 2000的错误日志文件中出现如下的错误：

2010-08-05 09:21:51.31 spid11    错误: 823，严重度: 24，状态: 2
2010-08-05 09:21:51.31 spid11    I/O error (torn page) detected during read at offset 0x0000116496a000 in file 'd:\Microsoft SQL Server\MSSQL\data\xxxxxxx_Data.MDF'.

======================================================

Description&Solution:

Torn_page_detection:
This recovery option allows SQL Server to detect incomplete I/O operations caused by power failures or other system outages.

When set to ON, this option causes a bit to be reversed for each 512-byte sector in an 8-kilobyte (KB) database page when the page is written to disk. If a bit is in the wrong state when the page is later read by SQL Server, the page was written incorrectly; a torn page is detected. Torn pages are usually detected during recovery because any page that was written incorrectly is likely to be read by recovery.

Although SQL Server database pages are 8 KB, disks perform I/O operations using a 512-byte sector. Therefore, 16 sectors are written per database page. A torn page can occur if the system fails (for example, due to power failure) between the time the operating system writes the first 512-byte sector to disk and the completion of the 8-KB I/O operation. If the first sector of a database page is successfully written before the failure, the database page on disk will appear as updated, although it may not have succeeded.

Note Using battery-backed disk caches can ensure that data is successfully written to disk or not written at all.

If a torn page is detected, an I/O error is raised and the connection is killed. If the torn page is detected during recovery, the database is also marked suspect. The database backup should be restored, and any transaction log backups applied, because it is physically inconsistent.

By default, TORN_PAGE_DETECTION is ON.

阅读全文…

标签: , , ,

关于sqlserver2005备份策略的一个问题

有这样一个备份策略：周一对某用户数据库进行完全备份，周二，周三一直到周日都进行日志备份。此策略简单易于说明本文的问题。

假如在周五的时候，其它地方需要使用此用户库的所有数据，而又不想拷贝周一的备份和后续的多个日志备份文件。此时，如何进行数据库全备呢？

如果做全备的话，则可能对原本运行正常的备份策略产生影响。此应用场景下，对用户库做了全备后，后续的周六、周日的日志备份所对应的基点就不是周一的全备而是周五的全备了。如果还按照原本的备份策略，则势必会出现问题。

如何在做数据库全备的时候，不影响原来的备份策略呢？

解决办法：

在sql server 2005 中有个参数 copy_only。

backup database andkylee to disk='d:\andkylee.bak' with copy_only

已为数据库 'andkylee'，文件 'andkylee' (位于文件 2 上)处理了 17296 页。
已为数据库 'andkylee'，文件 'andkylee_log' (位于文件 2 上)处理了 1 页。
BACKUP DATABASE 成功处理了 17297 页，花费 5.790 秒(24.471 MB/秒)。

成功！

 

————————————————————————————————-
—- 本文为andkylee个人原创，请在尊重作者劳动成果的前提下进行转载；
—- 转载务必注明原始出处 : http://www.dbainfo.net
—- 关键字：sql server 2005 备份 完全备份  with copy_only
————————————————————————————————-

阅读全文…

标签: , ,