⑴ sqlserver 2012日志满了导致数据库挂起恢复，如何解决
1、分离数据库
2、将日志改名，使数据库找不到日志文件。
3、附加，不带日志文件。附加的窗口中取消日志文件的选定。
这样，就会生成一个新的日志文件。
⑵ SQLServer数据库收缩相关知识
SQL Server 数据库采取预先分配空间的方法来建立数据库的数据文件或者日志文件，比如数据文件的空间分配了300MB，而实际上只占用了20MB空间，这样就会造成磁盘存储空间的浪费。可以通过数据库收缩技术对数据库中的每个文件进行收缩，删除已经分配但没有使用的页。从而节省服务器的存储的成本。
官方解释：收缩数据文件通过将数据页从文件末尾移动到更靠近文件开头的未占用的空间来恢复空间。在文件末尾创建足够的可用空间后，可以取消对文件末尾的数据页的分配并将它们返回给文件系统。
收缩后的数据库不能小于数据库最初创建时指定的大小。 或是上一次使用文件大小更改操作（如 DBCC SHRINKFILE）设置的显式大小。
比如：如果数据库最初创建时的大小为 10 MB，后来增长到 100 MB，则该数据库最小只能收缩到 10 MB，即使已经删除数据库的所有数据也是如此。
不能在备份数据库时收缩数据库。 反之，也不能在数据库执行收缩操作时备份数据库。
介绍：收缩指定数据库中的数据文件大小。
语法格式：
参数说明：
介绍：收缩当前数据库的指定数据或日志文件的大小，或通过将数据从指定的文件移动到相同文件组中的其他文件来清空文件，以允许从数据库中删除该文件。文件大小可以收缩到比创建该文件时所指定的大小更小。这样会将最小文件大小重置为新值。
语法格式：
参数说明：
例如，如果创建一个10MB 的文件，然后在文件仍然为空的时候将文件收缩为2 MB，默认文件大小将设置为2 MB。这只适用于永远不会包含数据的空文件。
另附SqlServer常见问题解答
1）管理器不会主动刷新，需要手工刷新一下才能看到最新状态（性能方面的考虑）
2）很少情况下，恢复进程被挂起了。这个时候假设你要恢复并且回到可访问状态，要执行：
RESTORE database dbname with recovery
这使得恢复过程能完全结束。
3）如果你要不断恢复后面的日志文件，的确需要使数据库处于“正在还原状态”，
这通常是执行下面命令：
RESTORE database dbname with norecovery
原来SQL Server对服务器内存的使用策略是用多少内存就占用多少内存，只用在服务器内存不足时，才会释放一点占用的内存，所以SQL Server 服务器内存往往会占用很高。我们可以通过DBCC MemoryStatus来查看内存状态。
SQL SERVER运行时会执行两种缓存:
1. 数据缓存：执行个查询语句，SQL SERVER会将相关的数据页（SQL SERVER操作的数据都是以页为单位的）加载到内存中来， 下一次如果再次请求此页的数据的时候，就无需读取磁盘了，大大提高了速度。
2.执行命令缓存：在执行存储过程，自定函数时，SQL SERVER需要先二进制编译再运行，编译后的结果也会缓存起来， 再次调用时就无需再次编译。
可以调用以下几个DBCC管理命令来清理这些缓存：
但是，这几个命令虽然会清除掉现有缓存，为新的缓存腾地方，但是Sql server并不会因此释放掉已经占用的内存。SQL SERVER并没有提供任何命令允许我们释放不用到的内存。因此我们只能通过动态调整SQL SERVER可用的物理内存设置来强迫它释放内存。
解决SQLSERVER内存占用过高的方法：
1、清除所有缓存DBCC DROPLEANBUFFERS
2、调整SQLSERVER可使用的最大服务器内存。
在SQL管理器，右击实例名称
在属性实例属性里面找到内存选项
把最大内存改成合适的内存，确定后内存就会被强制释放，然后重启实例。再看看任务管理器，内存使用率就降下来啦。
1、查看连接对象
USE master
GO
--如果要指定数据库就把注释去掉
SELECT * FROM sys.[sysprocesses] WHERE [spid]>50 --AND DB_NAME([dbid])='gposdb'
当前连接对象有67个其中‘WINAME’的主机名，‘jTDS’的进程名不属于已知常用软件，找到这台主机并解决连接问题。在360流量防火墙中查看有哪个软件连接了服务器IP，除之。
2、然后使用下面语句看一下各项指标是否正常，是否有阻塞，正常情况下搜索结果应该为空。
SELECT TOP 10
[session_id],
[request_id],
[start_time] AS '开始时间',
[status] AS '状态',
[command] AS '命令',
dest.[text] AS 'sql语句',
DB_NAME([database_id]) AS '数据库名',
[blocking_session_id] AS '正在阻塞其他会话的会话ID',
[wait_type] AS '等待资源类型',
[wait_time] AS '等待时间',
[wait_resource] AS '等待的资源',
[reads] AS '物理读次数',
[writes] AS '写次数',
[logical_reads] AS '逻辑读次数',
[row_count] AS '返回结果行数'
FROM sys.[dm_exec_requests] AS der
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50 AND DB_NAME(der.[database_id])='gposdb'
ORDER BY [cpu_time] DESC
查看是哪些SQL语句占用较大可以使用下面代码
--在SSMS里选择以文本格式显示结果
SELECT TOP 10
dest.[text] AS 'sql语句'
FROM sys.[dm_exec_requests] AS der
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50
ORDER BY [cpu_time] DESC
3、如果SQLSERVER存在要等待的资源，那么执行下面语句就会显示出会话中有多少个worker在等待
SELECT TOP 10
[session_id],
[request_id],
[start_time] AS '开始时间',
[status] AS '状态',
[command] AS '命令',
dest.[text] AS 'sql语句',
DB_NAME([database_id]) AS '数据库名',
[blocking_session_id] AS '正在阻塞其他会话的会话ID',
der.[wait_type] AS '等待资源类型',
[wait_time] AS '等待时间',
[wait_resource] AS '等待的资源',
[dows].[waiting_tasks_count] AS '当前正在进行等待的任务数',
[reads] AS '物理读次数',
[writes] AS '写次数',
[logical_reads] AS '逻辑读次数',
[row_count] AS '返回结果行数'
FROM sys.[dm_exec_requests] AS der
INNER JOIN [sys].[dm_os_wait_stats] AS dows
ON der.[wait_type]=[dows].[wait_type]
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50
ORDER BY [cpu_time] DESC;
4、查询CPU占用最高的SQL语句
SELECT TOP 10
total_worker_time/execution_count AS avg_cpu_cost, plan_handle,
execution_count,
(SELECT SUBSTRING(text, statement_start_offset/2 + 1,
(CASE WHEN statement_end_offset = -1
THEN LEN(CONVERT(nvarchar(max), text)) * 2
ELSE statement_end_offset
END - statement_start_offset)/2)
FROM sys.dm_exec_sql_text(sql_handle)) AS query_text
FROM sys.dm_exec_query_stats
ORDER BY [avg_cpu_cost] DESC;
5、索引缺失查询
SELECT
DatabaseName = DB_NAME(database_id)
,[Number Indexes Missing] = count(*)
FROM sys.dm_db_missing_index_details
GROUP BY DB_NAME(database_id)
ORDER BY 2 DESC;
SELECT TOP 10
[Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0)
, avg_user_impact
, TableName = statement
, [EqualityUsage] = equality_columns
, [InequalityUsage] = inequality_columns
, [Include Cloumns] = included_columns
FROM sys.dm_db_missing_index_groups g
INNER JOIN sys.dm_db_missing_index_group_stats s
ON s.group_handle = g.index_group_handle
INNER JOIN sys.dm_db_missing_index_details d
ON d.index_handle = g.index_handle
ORDER BY [Total Cost] DESC;
找到索引缺失的表，根据查询结果中的关键次逐一建立索引。
⑶ sqlserver 2012日志满了导致数据库挂起恢复，怎么解决
1、分离数据库
2、将日志改名，使数据库找不到日志文件。
3、附加，不带日志文件。附加的窗口中取消日志文件的选定。 这样，就会生成一个新的日志文件。
⑷ SQL数据库出现恢复挂起状态怎么办
SQL数据库出现恢复挂起状态怎么办
将SQL Server的启动帐号改为数据库文件中具有完全控制权限的本地管理员用户帐号，然后停止SQL服务并重新启动，就OK。
⑸ 服务器崩溃了进不去了怎么办
服务器数据恢复工程师对客户的服务器进行了初步检查，检查结果与客户描述及故障推测一致，服务器数据丢失的原因确实与异常断电有关，由于突然断电导致了启动信息丢失，另外客户服务器上的数据库也受到了破坏。想要恢复数据除了修复linux操作系统外还需要整理数据库碎片，修复数据库。
【服务器数据恢复过程】
服务器数据恢复工程师将客户服务器内的所有数据都按扇区备份到专用服务器上，将客户原始服务器状态复原，开始在专用服务器上进行数据分析和恢复。
linux系统修复后尝试启动服务器，服务器成功启动，但数据库无法启动，印证了之前工程师推测的数据库数据遭受破坏的推断。
数据恢复工程师继续分析数据库碎片数据，修改数据库错误数据，尝试修复并挂起数据库，最终成功恢复服务器内的数据库数据。交由客户对所有数据进行验证。
【服务器数据恢复结论】
经过客户对恢复数据进行验证，确认服务器及服务器上的数据库数据恢复完整、准确，本次数据恢复圆满成功。
【服务器数据恢复后记】
1、服务器故障后应避免随意拔插硬盘，避免硬盘盘序混乱。
2、避免对需要恢复数据的服务器进行写入和修改操作。
3、求助专业服务器数据恢复公司的专业服务器数据恢复工程师，切忌在未备份的情况对服务器进行操作。
⑹ 下载模拟器软件一直显示数据连接错误请联系管理员
1、登录账号、密码、服务器名称、数据库名称登录错误导致不能连接。解决方法：当正在使用的软件出现数据库不能连接时，一般就是服务器名出现问题，更改服务器名称一般可以解决问题。2、没能正确安装SQL服务器，也会导致数据库连接不上。解决方法：如果是SQL数据库未能能成功安装，再次重新安装时，可能会无法安装，提示是存在一个未完成的安装挂起。3、因权限问题导致数据库不能连接。解决方法：可以先暂时关闭防火墙或者杀毒软件，看是否是这些软件的安全设置所导致。(6)数据库回复挂起扩展阅读数据库连接的技术特点如下：1、采用复杂的数据模型表示数据结构，数据冗余小，易扩充，实现了数据共享。2、具有较高的数据和程序独立性，数据库的独立性有物理独立性和逻辑独立性。3、数据库系统为用户提供了方便的用户接口。4、数据库系统提供4个方面的数据控制功能，分别是并发控制、恢复、完整性和安全性。数据库中各个应用程序所使用的数据由数据库系统统一规定，按照一定的数据模型组织和建立，由系统统一管理和集中控制。5、增加了系统的灵活性。
⑺ 紧急求救，怎样才能恢复数据库
数据库被挂起了。你可以试一试用下面的方法恢复：
A.现象：Error 926
Severity Level 14
Error Message Text
Database 'xx' cannot be opened - it has been marked SUSPECT by recover Explanation
(1) 当你使用Transact_SQL命令操作这个数据库的数据时, 出现这个信息, 这是一个严重的错误, 如果你要使用这个数据库的数据, 必须改正这个错误.
(2) 启动Backup Server, 后备master数据库
1>mp database master to "/usr/sybase/master_mp.19991201"
2>go
(3) 用isql登录到SQL Server, 须用sa帐号 (本文以pubs2数据库为例)
1>sp_configure "allow updates", 1
2>go
1>begin tran
2>go
1>update master..sysdatabases
2>set status = -32768
3>Where name="pubs2"
4>go
如果得到(1 row affected),则
1>commit
2>go
否则
1>rollback
2>go
(4.1)如果条件允许，bcp out用户数据或mp用户数据库
(5.1)这时重新启动SQL Server, 再有sa帐号注册到SQL Server.
1>begin tran
2>go
1>update master..sysdatabases
2>set status=0
3>Where name="pubs2"
4>go
如果得到(1 row affected),则
1>commit
2>go
否则
1>rollback
2>go
1>sp_configure "allow updates" ,0
2>go
(4) 如果你的数据库原来有dboption(例如"select into","trunc log on chkpt"等), 你需要重新设置这些option..
(5) 运行dbcc命令检查数据库的一致性
isql -Usa -P -i dbcc.sql -o dbcc.out
dbcc.sql文件示例：
dbcc checkdb("pubs2")
go
dbcc checkalloc("pubs2")
go
dbcc checkcatalog("pubs2")
go
grep Msg dbcc.out
6) 后备用户数据库
1>mp database pubs2 on "/usr/sybase/pubs2_mp.19991201"
2>go
B.如何解决数据库被标记为"suspect"的问题之二（ 数据库设备损坏时的解决方案 ）？
A.现象： 926错误产生的原因有几种。本文讨论当数据库设备初始化失败( 设备文件丢失或文件读写权限不正确)时，导致数据库恢复失败，出现926错误的情况。
(1) 请先恢复数据库设备及读写权限。
(2) 启动Backup Server, 后备master数据库
1>mp database master to "/usr/sybase/master_mp.19991201"
2>go
3) 用isql登录到SQL Server, 须用sa帐号 (本文以pubs2数据库为例)
1>sp_configure "allow updates", 1
2>go
1>begin tran
2>go
1>update master..sysdatabases
2>set status = status - 256
3>Where name="pubs2"
4>go
如果得到(1 row affected),则
1>commit
2>go
否则
1>rollback
2>go
(4) 重新启动SQL Server, 运行dbcc命令检查数据库的一致性编辑生成dbcc.sql文件：
dbcc checkdb("pubs2")
go
dbcc checkalloc("pubs2")
go
dbcc checkcatalog("pubs2")
go
isql -Usa -P -i dbcc.sql -o dbcc.out
grep Msg dbcc.out
(5) 后备用户数据库
1>mp database pubs2 on "/usr/sybase/pubs2_mp.19991201"
2>go
⑻ 为什么还原sqlserver数据库的状态一直都是正在还原
1、可能是被用作镜像，被用作镜像有一个服务器是长期显示正在还原。
2、很少情回况下，恢复答进程被挂起了。这个时候假设你要恢复并且回到可访问状态，要执行：
RESTORE database dbname with recovery
⑼ sqlserver数据库恢复挂起怎么办
如果你的数据库还处于挂起状态，把我下面代码的test改为你的专库名，然后执行：属
USE master
GO
ALTER DATABASE test SET SINGLE_USER
GO
ALTER DATABASE test SET EMERGENCY
GO
DBCC CHECKDB(test,REPAIR_ALLOW_DATA_LOSS)
go
ALTER DATABASE test SET ONLINE
GO
ALTER DATABASE test SET MULTI_USER
GO
⑽ 网站宕机 服务器宕机 数据库宕机 宕机怎么办
最近遇到个比较有意思的问题，服务器宕掉后无法启动，想了好多办法，虽然解决了问题，数据没有丢失，但是没有按照自已的思路来，未免还是有些不甘。遇到问题不能慌，尤其是线上的环境，更不能紧张，心理素质对DBA来说也是一项挑战，可能你的手一抖就会导致多少人无法正常使用业务，如果你没有把握，请先把现场环境备份后再进行操作，避免数据的二次损坏，下面壹基比小喻说一下大概的思路吧。
1.检查是否有备份，如果备份存在，binlog存在，那么万事大吉，一切都有挽回的余地，慢慢来搞，只要你基础扎实，数据还原只是时间的问题。
2.对于没有备份的，那处理这个问题就有些棘手了，还得一步一步的来。
在my.cnf中[mysqld]下加上以下配置，采用强制恢复机制，看是否能够启动
[mysqld]
innodb_force_recovery=1
如果设置成1不能启动，可以逐渐的将数据增大到6，下文会详细说下1-6是什么意思，如果在1-6之间启动成功了，那么你运气还不错，这时候不要恢复业务，赶紧把数据用逻辑方式导出来，再启个新的实例把数据还原，有人会问，为什么mysql已经启动了，还要导出数据呢，原因在这：
当innodb_force_recovery被设置为大于0的时候 ，会阻止用户insert,update,delete也就是你启动的mysql不是一个正常的mysql服务，类似于windows系统下的安全模式。以下这段引于其它地方，具体地址不太清楚了，也可以从官方文档中找到。
innodb_force_recovery被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B树和其它数据库结构的更多破坏。
innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页，也让服务器运行着；试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表。
innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行，如果崩溃可能在净化操作过程中发生，这将阻止它。
innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并操作。如果你可能会导致一个崩溃。最好不要做这些操作，不要计算表统计表。
innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志：InnoDB把未完成的事务视为已提交的。
innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery被设置为大于0的值时，InnoDB阻止用户执行INSERT, UPDATE或DELETE操作.
即使强制恢复被使用，你也可以DROP或CREATE表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE导致的失控回滚。你可以杀掉mysqld进程，然后设置innodb_force_recovery为3，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。
关于上面进行逻辑备份也可能会遇到问题，可能会备份失败，如果出错，建议先按库一个一个的备份，到哪个库出错后，再按照当前库的表一个一个备份，表出错根据表中主键一点一点备份，最终将大部分数据导出。如果你的数据不重要，可以容忍丢失，那么可以当我说的都是废话了。
3.如果还是不可以启动，那么恭喜你，你遇到挑战了。
查看错误日志，看没有提示因为某个表的原因而导致启动不了，可以先把损坏的表的ibd文件先从数据目录mv走，再试着启动，在数据已经恢复后，我把当时错误的文件拿到本地，做了测试，把几个报错的ibd文件mv走后，数据库就可以正常启动了，但是mv走的这几个表数据会丢失。怎么把这个表的数据弄回来呢，曾想过用在线表空间传输，但是.cfg文件却没有，这种方法没有行通。后来用Percona Data Recovery Tool for InnoDB工具进行数据恢复，关于这个工具的介绍与操作，网上一大堆，我就不详细说明了。