查看: 144|回复: 1
关于MySQL数据库获得筛选数据问题，SQL大神请进！
阅读权限30
结帖率： (2/3)
&&_按钮1_被单击&&sql文本型&&data文本型&6recordset整数型&&i整数型&&行号整数型&&sql ＝ “SELECT * FROM info WHERE ” ＋ where ＋ “='” ＋ 到文本 (编码_Ansi到Utf8 (编辑框1.内容)) ＋ “'”如果真 (执行SQL语句 (sql_handle, sql))高级表格1.清空单元格数据 (1, 0, 高级表格1.行数, 高级表格1.列数)recordset ＝ 取记录集 (sql_handle)高级表格1.行数 ＝ 取记录集行数 (recordset)计次循环首 (取记录集行数 (recordset), i)处理事件 ()调试输出 (recordset) ' 开始获取数据库内容到指定行 (recordset, i － 1)读字段值 (recordset, 2, data [1])读字段值 (recordset, 3, data [2])读字段值 (recordset, 4, data [3])读字段值 (recordset, 5, data [4])读字段值 (recordset, 6, data [5])计次循环首 (高级表格1.行数, i)处理事件 ()如果真 (i ＝ 高级表格1.行数 － 1)高级表格1.行数 ＝ 高级表格1.行数 ＋ 1如果真 (高级表格1.取数据 (i, 0) ＝ “”)行号 ＝ i跳出循环 ()计次循环尾 ()处理事件 () ' 将获取到的数据写到表格内高级表格1.置数据 (行号, 0, 1, data [1])高级表格1.置数据 (行号, 1, 1, data [2])高级表格1.置数据 (行号, 2, 1, data [3])高级表格1.置数据 (行号, 3, 1, data [4])高级表格1.置数据 (行号, 4, 1, 到数值 (高级表格1.取数据 (行号, 2)) × 到数值 (高级表格1.取数据 (行号, 3)))计次循环尾 ()mysqlMySql支持库
eGrid高级表格支持库
spec特殊功能支持库
.版本 2
.支持库 mysql
.支持库 eGrid
.支持库 spec
.子程序 _按钮1_被单击
.局部变量 sql, 文本型
.局部变量 data, 文本型, , &6&
.局部变量 recordset, 整数型
.局部变量 i, 整数型
.局部变量 行号, 整数型
sql ＝ “SELECT * FROM info WHERE ” ＋ where ＋ “='” ＋ 到文本 (编码_Ansi到Utf8 (编辑框1.内容)) ＋ “'”
.如果真 (执行SQL语句 (sql_handle, sql))
& & 高级表格1.清空单元格数据 (1, 0, 高级表格1.行数, 高级表格1.列数)
& & recordset ＝ 取记录集 (sql_handle)
& & 高级表格1.行数 ＝ 取记录集行数 (recordset)
& & .计次循环首 (取记录集行数 (recordset), i)
& && &&&处理事件 ()
& && &&&调试输出 (recordset)
& && &&&' 开始获取数据库内容
& && &&&到指定行 (recordset, i － 1)
& && &&&读字段值 (recordset, 2, data [1])
& && &&&读字段值 (recordset, 3, data [2])
& && &&&读字段值 (recordset, 4, data [3])
& && &&&读字段值 (recordset, 5, data [4])
& && &&&读字段值 (recordset, 6, data [5])
& && &&&.计次循环首 (高级表格1.行数, i)
& && && && &处理事件 ()
& && && && &.如果真 (i ＝ 高级表格1.行数 － 1)
& && && && && & 高级表格1.行数 ＝ 高级表格1.行数 ＋ 1
& && && && &.如果真结束
& && && && &.如果真 (高级表格1.取数据 (i, 0) ＝ “”)
& && && && && & 行号 ＝ i
& && && && && & 跳出循环 ()
& && && && &.如果真结束
& && &&&.计次循环尾 ()
& && &&&处理事件 ()
& && &&&' 将获取到的数据写到表格内
& && &&&高级表格1.置数据 (行号, 0, 1, data [1])
& && &&&高级表格1.置数据 (行号, 1, 1, data [2])
& && &&&高级表格1.置数据 (行号, 2, 1, data [3])
& && &&&高级表格1.置数据 (行号, 3, 1, data [4])
& && &&&高级表格1.置数据 (行号, 4, 1, 到数值 (高级表格1.取数据 (行号, 2)) × 到数值 (高级表格1.取数据 (行号, 3)))
& & .计次循环尾 ()
就这个代码，凡是相符合的数据等于1，则提示数组错误。反则不会！求大神修改！！！
拒绝任何人以任何形式在本论坛发表与中华人民共和国法律相抵触的言论，本站内容均为会员发表，并不代表精易立场!
揭阳精易科技有限公司申明:我公司所有的培训课程版权归精易所有，任何人以任何方式翻录、盗版、破解本站培训课程，我们必将通过法律途径解决！
公司简介：揭阳市揭东区精易科技有限公司致力于易语言教学培训/易语言学习交流社区的建设与软件开发，多年来为中小企业编写过许许多多各式软件，并把多年积累的开发经验逐步录制成视频课程供学员学习，让学员全面系统化学习易语言编程，少走弯路，减少对相关技术的研究与摸索时间，从而加快了学习进度！
防范网络诈骗，远离网络犯罪
违法和不良信息举报电话，QQ： ，邮箱：@b.qq.com
Powered by
X3.2 揭阳市揭东区精易科技有限公司
粤公网安备 25下次自动登录
现在的位置:
& 综合 & 正文
sqlserver中char转化为varchar出现的问题-请数据库大神指点一二
Users数据库下
create table other_user (
id int identity(1,1) primary key not null,
name varchar(30),
pass varchar(30),
university char(20),
qq char(20));
这里我让id号自动增加。
我插入第一条数据记录：insert into other_user values('zhb','123','bnu','8888');作为登录验证
我一开始存储密码，这里是‘123’),用的是格式的，可以完成登录验证；但是后来
我用这条语句alter table other_user alter column pass char(10);
换成了数据类型的时候就不行了，应该是用的时候（定长的原因）出现了多余的空格，所以在“pass”).equals(pass)的时候为所以登录验证不了。此时的是类型的，更奇怪的是：我将的数据类型还原成原来的的时候，
alter table other_user alter column pass varchar(30);
再次使用之前的表中的那条记录进行登录验证，结果是登录不了。这是为什么了？
还没有结束，的数据类型还原之后，我再往表中插入一条数据，
insert into other_user values('bhz','321','bnu','8888');
对这条数据记录进行登录验证就可以了，奇怪了，难道是转换数据类型的时候，原来的数据所占的空间是不变的（从我这里来看，变成出现多余的空格，而变成是不是还保留着原来的空格呢？）。
这里使用和的时候要小心。
以下是我从其他地方找来的资料，本来想标注一下资料的处处，但是看到网上有太多是copy，鱼目混杂，也不知道谁是原创的，所以请原创者多多包含，也谢谢你的分享
1．char的长度是固 定的，而VARCHAR2的长度是可以变化的， 比如，存储字符串“abc"，对于char (20)，表示你存储的字符将占20个字节(包括17个空字符)，而同样的varchar2 (20)则只占用3个字节的长度，20只是最大值，当你存储的字符小于20时，按实际长度存储。由于char是以固定长度的，所以它的速度会比 varchar快得多!但程序处理起来要麻烦一点，要用trim之类的函数把两边的空格去掉!
2.char的效率比varchar2的效率稍高。
3．目前VARCHAR是VARCHAR2的同义词。工业标准的VARCHAR类型可以存储空字符串，但是oracle不这样做，尽管它保留以后这样做的权利。Oracle自己开发了一个数据类型VARCHAR2，这个类型不是一个标准的VARCHAR，它将在数据库中varchar列可以存储空字符串的特性改为存储NULL值。如果你想有向后兼容的能力，Oracle建议使用VARCHAR2而不是VARCHAR。
何时该用CHAR，何时该用varchar2？ CHAR与VARCHAR2是一对矛盾的统一体，两者是互补的关系. VARCHAR2比CHAR节省空间，在效率上比CHAR会稍微差一些，即要想获得效率，就必须牺牲一定的空间，这也就是我们在数据库设计上常说的‘以空间换效率’。 VARCHAR2 虽然比CHAR节省空间，但是如果一个VARCHAR2列经常被修改，而且每次被修改的数据的长度不同，这会引起‘行迁移’(Row Migration)现象，而这造成多余的I/O，是数据库设计和调整中要尽力避免的，在这种情况下用CHAR代替VARCHAR2会更好一些。
一般地说，只要一个表有一个字段定义为varchar(n)类型，那么其余用char(n)定义的字段实际上也是varchar(n)类型。 如果你的长度本身不长，比如就3～10个字符，那么使用char(n)格式效率比较高，搜索速度快。但是如果有的数据很长，有的数据有比较短，比如注册用户的简介这样的字段，实在没有办法，而且很在乎浪费的空间，那么就用varchar(n)格式。
Char,varchar,nvarchar字段是sql server数据库中的三种字段类型。好多人在选择存储的时候不知道如何抉择，我给大家讲下这个三个字段类型的区别。 Char(n)是长度为n个字节的定长的非unicode的字符数据。N为一个介于1到8000之间的值。其存储大小为输入数据的实际字节长度，而不是n个字节。如果你输入的实际字节长度少于n,那么其他位置会被空格填充。在数据存储中英文字母和数字占一个字节，汉字占两个字节。那么char(n)最多可以存储n个英文字母或数字，或者n/2个汉字。 Varchar(n)是长度为n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于1 和8,000 之间的数值。存储大小为输入数据的字节的实际长度，而不是 n 个字节。注意它和char(n)的区别是char(n)是定长的，varchar(n)是变长的。
如果你输入的字符的实际字节长度少于n,那么它的长度就是你实际输入的字节长度。在数据存储中英文字母和数字占一个字节，汉字占两个字节。Varchar(n)最多可以存储n个英文字母或数字，或者n/2个汉字。 Nvarchar(n) 包含 n 个字符的可变长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。字节的存储大小是所输入字符个数的两倍. 在数据存储中英文字母,数字,汉字都是占两个字节。Char(n)最多可以存储n个英文字母或数字，或者n个汉字。
在数据检索中，一般来说char型字段的数据是最快的，varchar,nvarchar型字段其次。 在所存数据长度不一的情况下，varcahr型字段所占空间最少，char,nvarchar其次。 那么到底在什么样的情况下使用什么样的数据类型那？ 如果你所存数据长度基本一致，建议使用char型。这样检索速度快，但是提取的时候要注意用trim()函数剔除所存数据两边的空格。 如果你所存数据长度差异较大，可以使用varchar或者nvarchar。如果你想较好的支持多语言的话，最好使用nvarchar。使用nvarchar可以减少字符转换问题，防止某些情况下乱码的出现。
说了这么多，大家可能都晕了。列个表供大家参考。 Char(n) Varchar(n) Nvarchar(n) N 最大值 00 数据长度固定（不足用空格填充）可变（实际数据长度）可变（实际数据长度）可存储最多英文（数字） 00 最多汉字数 00 英文（数字）所占字节 1 1 2 汉字所占字节 2 2 2 检索速度快慢慢在去年的一个网站项目中，我使用了sql server数据库，数据库排序规则为Chinese_PRC_CI_AS.其中部分字段使用varchar型。
我在本机浏览数据库中数据正常，页面数据显示正常。但是当我将数据库导入到服务器以后，在客户端发现页面从数据库中读取的数据显示全是乱码。我通过查询分析器连接到服务器，发现数据库中的汉字也全变成了乱码。 我估计服务器端sql server为英文版，于是将服务器数据库中varchar型字段都改为nvarchar型，乱码问题解决。但是同时我又发现一个奇怪的现象。
比如数据库中有两个记录。 表名： ComputerInfo Computer computerType 成都家具厂 私营 合肥家具厂 私营 其中Computer字段为nvarchar型。我用 select * from ComputerInfo where Computer like ‘%成都%’ 返回的记录数总是0.奇怪了，明明数据库中有数据的嘛。我查阅了大量的资料以后，终于解决了问题。只需要把查询语句改为select * from ComputerInfo where Computer like N‘%成都%’ 即可。在字符前加N表示将其转化为unicode字符。原文出自：
【上篇】【下篇】安装SQL Server 2008 注意及问题解决_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
安装SQL Server 2008 注意及问题解决
&&自己写的安装过程,完全卸载以及遇到问题的解决
阅读已结束，下载本文需要
想免费下载更多文档？
定制HR最喜欢的简历
下载文档到电脑，同时保存到云知识，更方便管理
加入VIP
还剩17页未读，
定制HR最喜欢的简历
你可能喜欢目前SQL Server数据库作为微软一款优秀的RDBMS，其本身启动的时候是很少出问题的，我们在平时用的时候，很少关注起启动过程，或者很少了解其底层运行过程，大部分的过程只关注其内部的表、存储过程、视图、函数等一系列应用方式，而当有一天它运行的正常的时候突然启动不起来了，这时候就束手无策了，能做的或许只能是重装、配置、还原等，但这一个过程其实是一个非常耗时的过程，尤其当我们面对是庞大的生产库的时候，可能在这火烧眉毛的时刻，是不允许你再重搭建一套环境的。
所以作为一个合格的数据库使用者，我们要了解其启动、运行过程的事情，一旦发生问题，我们也能及时定位，迅速解决。
闲言少叙，我们进入本篇的正题。&
SQL Server本身就是一个Windows服务，每一个实例对应的就是一个sqlserver.exe进程。这是一个可执行的文件，默认就放在SQL Server的安装目录下，当我们启动的时候，就是直接调用这个文件，然后启动这个服务。&
第一部分、SQL Server实例启动的方法和启动所发生的问题
& SQL Server实例分为下面几种启动方法：
（1）在Windows服务控制台里手动启动，或者自动启动（默认），这个也是最常用的方式
（2）第二种方式是SQL Server本身自己提供的启动方式，我们这里可以手动启动
（3）在SQL Server的SSMS里面手动启动它，这个方式一般大部分利用这种方式进行手动重启
（4）通过Windows命令窗口，用'net start'命令手动启动，这种方法也可以用
以上这几种方式都可以启动SQL Sever,并且都会在SQL 日志信息中有所记录。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第二部分、SQL Server实例启动的详细过程以及所发生的问题项
第一步、检查注册表项
当一个sqlserver.exe文件开始启动的时候，首先要干的第一件事就是先检查它的配置信息存放于注册表的值项
比较重要的几个键值有下面几个：
AuditLevel:其实就是SQL 如何记录用户登录记录；
LoginMode:是SQL Server服务器身份验证方式等；
BackupDirectory:默认的备份路径等信息；
关于注册表信息简要了解即可，不建议做任何修改，当然这些值的信息默认在SQL Server中都能设置：
在不修改注册表的情况下，一般这一步的启动顺序一般不会出现问题，当然出现问题了也通常没有办法解决，大部分的解决方式只有重装了。
但这一步骤，通常出现以下两个个问题通常是可以解决的：
&1&启动账号权限问题
如果我们启动SQL Server的进程使用的账号连读注册表的权限都没有，那这个服务是怎么也启动不了的，通常这时候连SQL 的错误日志都没有能力生成出来。
这时候我们该如何发现呢，虽然这时候它没有能力创建SQL 的错误日志，但是它在Windows层面留下了痕迹，我们来看：
我将服务启动账号设置成gust来宾账号，来启动该服务
这时候会产生以下错误信息：
在Windows的日志信息里也会产生一条错误日志记录：
这里的拒绝访问指的就是拒绝访问注册表信息了。
解决方法：
此问题的解决方式就很简单了，只需要将当然的用户提权到SQL Server服务的启动账号就行了，提权的方式也很简单，只需要添加到SQL的本地用户的启动服务组就可以了。
当然，也可以直接换一个更高级别的用户登录。一般默认都用的超级管理员账户。
&2&访问日志和文件夹出现问题
默认在SQL Server启动的时候会创建一个启动日志文件，记录所有正确的日志信息，当然也包括错误的日志信息，如果这时候找不到这个日志信息的路径，或者已经存在一个日志，但是日志被锁定了（某些NB的杀毒软件擅长干这个），这时候这个服务也是启动不了的，同样也创建不出SQL Server的日志文件，这时候我们还得借助于Windows平台本身，来解决。
SQL Server启动的创建的日志文件路径，同样存在于注册表项里，我们来看这个参数：
这里我们故意改成一个错误的路径，来启动下看看：
会产生以下错误
系统的错误日志信息
错误说明的很清楚。
解决方法：
这个问题解决起来也很简单，只需要检查好该路径，确保路径下的文件正确就可以。
不过有一点需要注意，当SQL Server还没启动起来的时候，有部分错误信息日志需要检查Windows平台下的系统日志。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
&第二步、检查系统配置环境，包括硬盘、内存与CPU等
当我们进行完第一步的时候，SQL Server已经读取完注册表信息，完成了它的errorlog文件的创建，然后开始进行第二步的进行，这一步骤所有的信息就会按照顺序依次记录到errorlog文件中，我们可以通过查看该文件来详细跟踪这一步骤的进行，根据上一步的注册表信息，我们先来手动清空下这个日志，然后重启一下SQL Server服务，查看下这个日志记录
我们简单大致分了以下几大步骤：
一、首先检查系统的软件环境，包括OS版本、电脑信号、内存、硬盘、注册表基础配置项是否正确等
二、启动系统数据库master
三、开始利用服务用户登录系统、启动系统资源数据库、检查数据库版本信息等
四、启动系统数据库model
五、开始网络配置进行连接，对外提供服务，使用的默认的1433端口
我们接着分析下面的日志：
六、其实完成上面的第五步之后，也就开始启动msdb系统数据库
七、这时候开始真正的启动用户数据库，并且完整各个库的完整性校验，并且在启动用户数据库之前，先将系统库的tempdb进行清空
八、在搭建完成之后，才开始启系统的另外一个数据库tempdb
上面的整个SQL& Server系统启动的过程产生了详细的日志记录，我们下面会依次按照该步骤进行详细的进行逐步分析。
在检查系统软硬件环境的过程中，基本不会发生什么致命错误。比较常见的问题就是内存配置问题，其实在上面的日志记录中有一句特别重要，它反映的就是SQL Server利用内存的情况，我们来看：
这句话的意思是将所有的数据页锁定到内存中，作为大部分数据库而言，内存就是生命线，SQL Server同样也是，如果系统（64bit中）没有内存压力的情况下，才能将数据页正常的锁定到内存中，如果内存压力过大，系统内存是不允许将数据页也加入到内存中，而这样导致的问题就是SQL& Server严重的性能问题。
很多用户希望限制SQL Server内存使用，并且有些客户机将它限制到服务都不能启动的情况，这时候在SQL Server的日志中是这样展现的，我们来看：
可以看到，该错误的原因还是挺清楚的，修复该错误的解决方法也很简单，将内存配置调大就可以。
跟内存有关的还有一种特殊的情况，就是SQL Server的启动账号在服务器上没有Lock page in memory的权限，如果没有这个权限，在明细日志中查看不到上面的日志记录，该问题的解决方法也很简单，只需要将需要权限加上就可，加权限的方式如下：
经过上面的步骤基本，完成数据的软硬件检测过程。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
&第三步、启动系统数据库master
master数据库是SQL Server系统启动过程中的第一个系统库，是非常关键的数据库。如果这个库不能被正常打开，则SQL Server就不能正常启动。
和其它数据库一样，master数据库也分为数据文件和日志文件，启动的过程是依次打开，然后做恢复动作，如果这个过程没问题的话，在Errorlog日志文件中，我们会看到如下的这句话：
如果这个过程出现了任何问题，SQL Server的启动过程都会被中断，启动过程失败。
而这个过程发生的错误，无非就集中以下几种情况，我们来分析一下：
&1&在指定的路径找不到master数据的数据文件或日志文件
关于这个SQL Server的最主要的系统数据库的路径，它是以注册表形式存在的，在一下注册表项，可以看到
如果在该路径下找不到这个系统数据库的话，服务是启动不了的，并且会产生相应的错误日志信息，我们来模拟下，关掉服务，将这两个文件移除走，然后启动看一下：
首先，该服务是启动失败的
我们来看一下系统日志
看Errorlog的日志信息
可以看到，该问题提示错误信息还是挺详细的。我们来看第二种情况
&2&文件找到了，但是没有权限访问，或者不能以排他的方式打开该文件（默认的是独占锁进行文件打开的）
此种情况也是有可能产生的，比如某些NB的杀毒软件就可以干这个事，让你的系统库无法访问，这样同样也是启动不了的，我们这样来看，提示的错误的信息有哪些：
来看Errorlog的错误记录：
&3&文件找到了，访问权限也有，但是文件有问题，就是说是数据库损坏了
这个问题也经常出现，比如磁盘坏掉了，恢复后发现文件有问题，不能正常打开，这种问题我们来看错误信息：
日志中的信息
关于master系统库的启动过程，基本就是上面的三种错误，关于这三种问题，我们该如何解决呢？
解决方法：首先如果根据错误日志定位出问题的性质，如果是前两种问题其实是挺好解决的，比如文件没找到、权限项不对等，这些问题相应的去解决就可以，最棘手的就是第三种情况，出现这种情况最理想的情况是master数据库进行了备份，通过备份文件进行恢复就可以，一切就可以正常，当然通过暴力的停掉服务，拷贝文件进去也可以解决。
最揪心的就是这个库就没备份，那该如何解决呢？这种方式的解决就得借助SQL Server的安装程序，进行重建master数据了，但是这种方式重建的master数据库会导致以前的SQL Server的设定全部清空掉。
清空的信息包括：所有的账户信息（意味着需要重建）、msdb中的所有job信息等（也需要重建）、用户数据库信息（必须全部重新附加attch上）
而这一系列过程如果是一个生产库，可能会是一个非常大的工作量！
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
&第四步、启动系统资源数据库，并检查数据版本信息
资源数据库是SQL Server2005中引入的逻辑数据库，在实例下是看不到的，但是有它的物理文件，主数据库默认名称为：mssqlsystemresource.mdf、日志名称为：mssqlsystemresource.ldf
如果该数据库启动的过程中也出现了问题，那SQL Server也不能正常启动。
这个系统数据库比较特别，它是一个只读数据库，完全由SQL Server自己维护，用户是不能更改的，所以我们只要保证它的是数据库文件和日志完好就可以，不需要对它进行任何的跟踪和维护。
当然如果非要看这个数据库，可以通过单用户的DAC方式进行连接。
所以这个数据库在一般情况下不会发生意外，基本上是能正常启动，不过特殊情况下，不能启动的情况就以下两种：
&1&数据库文件不存在，无法访问，或者文件坏掉了
其实它的报的错误信息，类似于上面的master数据库，我来截个图，看一下：
这个是errorlog记录的错误信息
在windows层面也有它自己的错误日志信息：
&2&资源数据库的版本和SQL Server的版本不一致
这个有可能是人为的更改了这个资源数据库，导致现有的资源数据库文件和数据库版本不一致，这样的话也会导致错误的形成
windwos平台也记录下了该错误的信息，看下面的图片：
解决方法：
关于资源库的这两个问题解决方法，非常的简单。只要找到和这台服务器上的SQL Server的版本一致的数据库，拷贝过来就行。
当然最好的预防措施是：每当安装完SQL Server或者打完补丁之后，就及时的备份这个两个文件，放在安全的地方，用的时候拷贝过来就行，备份是数据库管理员的天职
当然有时候在紧急的情况下，找不到相同版本的数据库，理论上这个库是只读的，所以不会发生任何改变，我们随便找一台机器，安装一下同版本数据库，然后拷贝过来就行，当然一定注意的是这里面是相同版本。&
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第五步、启动系统数据库model
model系统数据库同样也是SQL Server启动过程中用到的一个非常关键的数据库，如果这个库损坏，SQL Server启动也会失败，关于model数据不能启动的原因基本和master的类似，同样也是两种：1、数据库文件早不到或者不能访问；2、数据库文件能访问但是是损坏的文件。
诊断此种问题的方式也和上面的两种方式一样，查看启动过程产生的errorlog文件或者windows系统日志，这里我们就不重现该问题了。
我们只给出此种问题的解决方法：
1、如果该库我们已经做过备份，那最直接也是最有效的解决方式就是直接还原，这里的还原方式可能和普通库的还原方式不一样，因为SQL& Server实例还没有启动，我们恢复过程采取以下过程：
a.用参数启动SQL Server，在命令提示行中执行以下命令，这样的话SQL Server启动就会跳过model数据库恢复这一步
net start MSSQLSERVER /f /m /T3608
b.现在恢复model数据库，打开SSMS，直接输入
RESTORE DATABASE model FROM DISK ='G:\data\model.bak'
MOVE 'modeldev' TO 'E:\dataDefaultFileManger\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.mdf'
MOVE 'modellog' TO 'E:\dataDefaultFileManger\MSSQL10.MSSQLSERVER\MSSQL\DATA\model.ldf'
c.恢复成功后，直接重启SQL Server既可以。
2、将SQL Server关闭，然后直接采取暴力的方式将model数据文件拷贝回来就可以，这种方式简单有效，但是非常规操作
3、还有一种方式是利用setup安装文件，重建该数据库，过程缓慢，稍显复杂，很不推荐。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第六步、开始网络配置进行连接，对外提供服务，使用的默认的1433端口
当上面的几个重要的系统库都已经启动完成之后，下一步就是开始检查网络环境，进行网络服务的配置，对外进行提供服务了，一般来讲，在SQL Server中利用的网络启动协议有三种：Shared Memory、Named Pope和TCP/IP，其实在日常我们最常用的就是TCP/IP这种方式了，并且默认开启的是1433端口。
我们来看一下正常启动过程中，该部分的详细日志：
这里面的Shared Memory是专供本地连接通过LPC(Local Procedure Call)技术向SQL Server做的连接。它不走网络层，所以他是速度最快的连接方式。正常启动后会显示上面的正常日志。
Named Pipe方式正常启动，也会显示出上面的日志。可以看到。
这其中我们最常用的TCP/IP这种方式，也正常的启动了，并且指定了两种访问方式，ipv4/ipv6，然后后面加上了1433端口号。
在这个过程中最常出现的问题就是，1433端口被其它程序占用，这样就导致TCP/IP协议无法正常启动，这样我们会看到如下日志信息
并且在windows 系统日志中也会有记录
解决方法：
其实这里出现的问题还是挺好解决的，只需要找到占用这个端口的应用程序，采取措施让它把这个端口给让出来就可以。
当然出现这些问题就意味着客户端已经无法通过TCP/IP这种远程连接的方式进行连接访问了。
这时候一般管理员可以采用SQL Server给其提供的&专用管理员连接&（DAC）进行连接，这种方式我们以后再介绍。
当然，在SQL Server启动的过程中，一般出现这种网络问题，或者协议不能成功加载，SQL Server会报出错误信息，但是一般情况下是不会影响SQL Server的正常启动的。受影响的可能只是出问题的那种协议功能。
我们只需要根据日志，定位问题，然后解决掉，重新启动就可以了。
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第七步、开始启动msdb系统数据库
关于msdb这个系统数据库，它是被安排在系统库中接近最后一个了，除了用户数据库和临时库tempdb之外，当启动过程中已经进行到这一步的时候，其实我们的实例就已经启动起来了，并且能够连接。
我们知道msdb这个库中主要的存储的信息是应用各个库的备份信息，各种job的历史跑批信息等，其实诸多的都是来自于用户数据库所产生的一些客观数据。
我们来看一下这个库出现了问题会产生什么现象：
我将这个库文件移除走，然后重新启动服务，启动过程中没有报任何错误，并且能够顺利启动，我们用SSMS直接连接过去，也可以正常连接
但是当我们点击开数据的时候，其实是看不到任何用户数据库的，并且会产生一个错误提示：
看来是不能使用的，我们来查看一下错误日志：
虽然这个库的重要性比起master之类的库重要性要稍显差一些，但是缺少了它我们的SQL Server虽然能启动，但是依然不能使用。
解决方法：
要解决这个问题其实方式就很多种了，因为到此我们的SQL Server实例已经能够正常启动了，我们可以采取：
1、利用备份还原该库，参考文章前面的方式（推荐）
2、关掉服务，利用暴力的拷贝文件的方式进行恢复，简单有效，非常规操作
3、找台相同的环境，找到相同的文件，直接拷贝过来使用
4、利用安装文件进行恢复（不推荐）
----------------------------------------------------------霸气的分割线-----------------------------------------------------------------------
第八步、启动用户数据库，并且完整各个库的完整性校验，并且在启动用户数据库之前，先将系统库的tempdb进行清空
本步骤所遇到的问题层出不穷，各种样式，我打算再重新组织一篇文章，专门列举，此篇就不介绍了。
但有一点需要记住：在这一步之前SQL Server会将tempdb这个系统库清空掉，也就是说，每次的重启操作，系统都会将tempdb清空，然后重建，这一步一般不会发生异常，成功之后会出现以下日志信息：
第九步、开始重建系统的另外一个数据库tempdb
tempdb这个库比较特殊，每次重启的时候都是重新创建的，SQL Server会根据master数据库里的记录的信息以model数据库为版本进行创建。所以只要我们保证model数据库没有问题，然后硬盘没有问题，tempdb的数据库文件就应该没有问题。
关于temdb这个库的所有配置信息是存储于master的数据库中的，里面的内容信息是存储于model系统库中的
这样就带来了一个问题，有时候我们的master的库是从别的机器下面备份下来的，所以它里面会记录这个tempdb这个库在原来机器上的路径，这样在启动创建的时候就会报错。
所以我们需要执行以下命令更改这个库路径
a、用参数启动SQL Server
net start MSSQLSERVER /f
b.修改数据文件和日志文件路径
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:\right path....\temdb.mdf');
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,FILENAME='C:\right path....\temdblog.ldf');
c.正常启动数据库既可以
还有一种情况，就是创建该文件的时候，提供的硬盘空间不足，或者权限不够，我们也是根据上面的方式，修改到一个正确的路径，并且确保权限正确。
也可以更改temp文件的大小，默认是4M，代码如下：
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,SIZE=100MB);
ALTER DATABASE tempdb MODIFY FILE(NAME=tempdev,SIZE=100MB);
至此，如果上面的整个过程都没出问题的话，一个正常的SQL Server就可以启动成功的。
本篇文章到此结束了.....此篇耗时三天.....为了尽可能的呈现出所有的问题现象，我对本地的SQL Server进行了多种无情的蹂躏、各种的摧残，力求能够重显各种不同的应用场景问题现象，然后尽可能的找到合适的解决方案，当然还有很多的情况没有展现出来，后续遇到，会一一补充进来，当然有遇到不能解决的，也可以留言，我们一起分析解决。
关于用户数据库启动过程，这个过程是一个问题较易发生的步骤，神马质疑、恢复中、不可用等等现象，我后续的文章中列举分析。
已经补充出该篇的关联篇：
如果您看了本篇博客,觉得对您有所收获，请不要吝啬您的&推荐&。&
阅读(...) 评论()