SQL Server

SQL SERVER LDF日志文件太大的解决方法

六月ゝ 毕业季﹏ 提交于 2020-04-25 03:05:49
如何压缩日志及数据库文件大小 /*--特别注意 请按步骤进行,未进行前面的步骤,请不要做后面的步骤 否则可能损坏你的数据库. 一般不建议做第4,6两步 第4步不安全,有可能损坏数据库或丢失数据 第6步如果日志达到上限,则以后的数据库处理会失败,在清理日志后才能恢复. --*/ --下面的所有库名都指你要处理的数据库的库名 1.清空日志 DUMP TRANSACTION 库名 WITH NO_LOG 2.截断事务日志: BACKUP LOG 库名 WITH NO_LOG 3.收缩数据库文件(如果不压缩,数据库的文件不会减小 企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 也可以用SQL语句来完成(注:根据我的实践,用企业管理器执行收缩操作后,ldf文件大小并没有发生变化,用下面的SQL指令就可以) --收缩数据库 DBCC SHRINKDATABASE(库名) --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles DBCC SHRINKFILE(1) 4.为了最大化的缩小日志文件

为什么作为下游的WSUS更新服务器总有一直处于下载状态的文件

痴心易碎 提交于 2020-04-25 02:20:30
在 上一篇关于WSUS无法更新Win10 1809 之后,最近又遇到了下游服务器不正常的问题,而且在交流群中有群友问过这类问题…… 问题现象: 在下游服务器上使用同步更新后会看到一个一直处于需要文件的更新。 图 1 一直处于需要文件的更新 根据我的观察,最近几天一直都有,由于前一段时间修理了一下下游更新服务器,因大量文件需要同步,就一直等数据同步,可最近一段时间经常能看到这个,感觉到可能是哪里有问题,需要根据这个不正常的现象进行问题排查。 解决问题: 借助 HTTPNetworkSniffer 嗅探工具 ,找找看 HTTP 请求中的不和谐反馈。 在点击立即同步后没多久,就在工具中看到了反馈 404 这个错误。 图 2 无法获取上游服务器中的更新文件 通过猜测 esd 文件的性质,和图 1 中文件大小, 估摸着 可能就是这个文件。 【 ESD 文件是用来升级操作系统,尤其是 Win10 更新的一种加密压缩文件,因此等同于一个操作系统的 WIM 文件,所以体积比较大是正常的】 在上游更新服务器上搜索这个文件 “ A7497EF7AFF694250BE967D2D10C6116A5D26523.esd ” 无果,可以确定问题应该存在于上游服务器。 对于 WSUS 更新服务器的设计框架是有一个数据库(通常是系统内建的 SQLServer 或者 WID )记录补丁信息,一个叫做 WSUS

读书笔记——商广明《Nmap渗透测试指南》

拟墨画扇 提交于 2020-04-25 02:00:03
一 Nmap基础学习 1.简介及安装 Nmap是一款由 C语言编写 的、 开源免费 的网络发现(Network Discovery)和安全审计(Security Auditing)工具。软件名字Nmap是Network Mapper的简称。Nmap最初是由Fyodor在1997年开始创建的。随后在开源社区众多的志愿者参与下,该工具逐渐成为最为流行安全必备工具之一。 Nmap是一个开源的网络连接端扫描软件,用来扫描计算机开放的网络连接端。确定哪些服务运行在哪些连接端,并且推断计算机运行哪个操作系统,它是网络管理员必用的软件之一,以及用于评估网络系统安全。 Nmap可以快速地安装到Windows、Linux、Mac等操作系统中。Nmap的安装包可以从https://nmap.org/download.html进行下载。Windows下直接双击安装。 如今Nmap更是增加许多实用的插件,可以用来检测SQL注射、网页爬行、数据库密码检测等,号称扫描之王。欲了解更多信息请登录官网:https://nmap.org/。 Nmap官方参考指南: https://nmap.org/man/zh/index.html 。 2.Nmap常用命令 Nmap最常用的参数总结如下: Nmap扫描案例: 基本扫描 nmap 192.168.126.131 注意:Nmap默认仅扫描主机1000个高危端口

超详细!! sql server 同步数据库 发布 订阅 跨网段 无公网ip 常见问题

醉酒当歌 提交于 2020-04-25 01:52:18
问题描述 主机1:发布端 阿里云服务器--有公网ip 主机2:订阅端 笔记本--无公网ip 数据量很小,主要是熟悉发布订阅的操作流程。 主机2仅仅作为主机1的本地备份,要求修改云服务器上数据后,能通过sql server的发布订阅功能将本地数据同步。 底下没有一步一步介绍,一步一步的,可以看下面这篇 https://blog.csdn.net/u012861467/article/details/76411216 ---------------------------------------------------------------------------------------------- 问题1 阿里云的sql server配置好后,无法使用本地sql server客户端远程登录。 检查以下几点 1.要在阿里云的控制台中的防火墙, 打开阿里云的1433端口 (默认的sql server访问端口) 这点很重要,好多教程里没有提到!!! 2.要把两台主机的sql manager中的sql server服务中的sql server代理打开(原本是禁用状态) 3.远端服务器要开启sql server用户名密码登录方式,并且设置好代理账号和密码 到这一步,应该可以在笔记本的sql server通过ip地址,和刚刚设置的代理账户和密码登录进云服务器了。 --------------

syspolicy_purge_history作业故障排除

蹲街弑〆低调 提交于 2020-04-25 01:52:03
描述 我们有一台数据库服务器windows 2012 r2 上有安装sql server 2012 和sql server 2016双实例,后续又把sql 2016的服务全部停用,即只保留sql 2012 的服务在用。在例行检查数据库的job 运行情况时发现syspolicy_purge_history该自带的job一直是失败的,错误一直停留在step 3, 首先先了解一下该job的官方文档说明 ,发现虽然跟实际在用的业务功能没有什么关联,但还是觉得有必要修复。 操作步骤 a.查看job的具体报错提示 消息 已以用户 XXXXXXXXX 的身份执行。 作业步骤在 PowerShell 脚本的行 1 中接收到错误。对应行为“import - module SQLPS - DisableNameChecking”。更正脚本并重新安排作业。PowerShell 返回的错误信息为“未能加载文件或程序集“ file : /// C:\Program Files (x86)\Microsoft SQL Server\ 130 \Tools\PowerShell\Modules\SQLPS\Microsoft.SqlServer.Management.PSSnapins.dll”或它的某一个依赖项。生成此程序集的运行时比当前加载的运行时新,无法加载此程序集。 ”. 进程退出代码 - 1 。.

备份链中断导致差异备份报错案例

三世轮回 提交于 2020-04-25 01:51:53
原文: 备份链中断导致差异备份报错案例 最近一台SQL Server服务器部署SQL Server Backup后,发现每晚的差异备份老是失败,报如下错误: Msg 3035, Level 16, State 1, Line 1 无法执行数据库"xxxx" 的差异备份,因为不存在当前数据库备份。请去掉WITH DIFFERENTIAL 选项后重新发出BACKUP DATABASE 以执行数据库的完整备份。 Msg 3013, Level 16, State 1, Line 1 BACKUP DATABASE 正在异常终止。 出现这个错误,一般是因为没有做过完整备份或备份链中断(chain of backups to break),仔细检查后发现完整备份存在,那么就可能是备份链中断所致,检查备份日志记录: SELECT CONVERT ( CHAR (100), SERVERPROPERTY( 'Servername' )) AS server_name , bs.database_name , bs.backup_start_date , bs.backup_finish_date , bs.expiration_date , CASE bs.type WHEN 'D' THEN 'Full Backup' WHEN 'I' THEN 'Diff Backup' WHEN 'L'

SQL SERVER占用服务器内存过高的解决方案

戏子无情 提交于 2020-04-25 01:51:25
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。 本文链接:https://blog.csdn.net/xiaogang107/article/details/89878583 SQL Server对服务器内存的使用策略是用多少内存就占用多少内存,只用在服务器内存不足时,才会释放一点占用的内存,所以SQL Server 服务器内存往往会占用很高。 这些内存一般都是SQL Server运行时候用作缓存的: 1. 数据缓存:执行个查询语句,SQL Server会将相关的数据页(SQL Server操作的数据都是以页为单位的)加载到内存中来, 下一次如果再次请求此页的数据的时候,就无需读取磁盘了,大大提高了速度。 2.执行命令缓存:在执行存储过程,自定函数时,SQL Server需要先二进制编译再运行,编译后的结果也会缓存起来, 再次调用时就无需再次编译。 调用以下几个DBCC管理命令来清理这些缓存: DBCC FREEPROCCACHE 清除存储过程相关的缓存 DBCC FREESESSIONCACHE 会话缓存 DBCC FREESYSTEMCACHE('All') 系统缓存 DBCC DROPCLEANBUFFERS 所有缓存 但是,这几个命令虽然会清除掉现有缓存,为新的缓存腾地方,但是SQL

DBCC SHRINKFILE收缩日志/收缩数据库/收缩文件

我是研究僧i 提交于 2020-04-25 01:51:12
DBCC SHRINKFILE 收缩相关数据库的指定数据文件或日志文件大小。 语法 DBCC SHRINKFILE ( { file_name | file_id } { [ , target_size ] | [ , { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ] } ) 参数 file_name 是已收缩文件的逻辑名称。文件名必须符合标识符的规则。有关更多信息,请参见 使用标识符 。 file_id 是要收缩的文件的标识 (ID) 号。若要获得文件 ID,请使用 FILE_ID 函数或在当前数据库中搜索 sysfiles。 target_size 是用兆字节表示的所要的文件大小(用整数表示)。如果没有指定,DBCC SHRINKFILE 将文件大小减少到默认文件大小。 如果指定 target_size ,DBCC SHRINKFILE 将试图将文件收缩到指定大小。将要释放的文件部分中的已使用页将重新定位到保留的文件部分中的可用空间。例如,如果数据文件为 10MB,则带有 target_size 为 8 的 DBCC SHRINKFILE 将导致文件最后 2 MB 中所有已用页重新分配到文件前 8 MB 中的任何可用槽中。DBCC SHRINKFILE 不会将文件收缩到小于存储文件中的数据所需要的大小。例如,如果使用 10MB

Linux安装MSSQL2017使用mssql-conf配置参数

痞子三分冷 提交于 2020-04-25 01:40:35
Linux上安装SQL Server 2017 1.下载 Microsoft SQL Server 2017 Red Hat 存储库配置文件: sudo curl -o /etc/yum.repos.d/mssql-server.repo https://packages.microsoft.com/config/rhel/7/mssql-server-2017.repo 2.运行以下命令以安装 SQL Server: sudo yum install -y mssql-server 3.包安装完成后,运行 mssql-conf setup,按照提示设置 SA 密码并选择版本。 sudo /opt/mssql/bin/mssql-conf setup 4.systemctl status mssql-server systemctl status mssql-server 5. 防火墙上打开 SQL Server 端口。 默认的 SQL Server 端口为 TCP 1433 sudo firewall-cmd --zone=public --add-port=1433/tcp --permanent sudo firewall-cmd --reload 安装方法 2 : wget https://packages.microsoft.com/rhel/7/mssql-server

SQL Server作业报错特殊案例

随声附和 提交于 2020-04-24 23:29:28
一个作业报错,报错信息如下,从错误信息根本看不出为什么出错,手工运行作业又成功了。一时不清楚什么原因导致作业出错。 Message Executed as user: NT SERVICE\SQLSERVERAGENT. ...eration. [SQLSTATE 01003] (Message 8153) Mar 6 2019 8:09AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:10AM [SQLSTATE 01000] (Message 0) Mar 7 2019 8:17AM [SQLSTATE 01000] (Message 0) Mar 6 2019 11:17AM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:03PM [SQLSTATE 01000] (Message 0) Mar 6 2019 4:06PM [SQLSTATE 01000] (Message 0) Mar 7 2019 4:07PM [SQLSTATE 01000] (Message 0) Mar 6 2019 1:40PM [SQLSTATE 01000] (Message 0) Mar 7 2019 1:36PM [SQLSTATE 01000] (Message 0) Mar 6 2019 8:02AM