我目前正在使用 Tortoise SVN 对 .NET Web 应用程序进行源代码控制。将我们的 SQL Server 存储过程引入源代码管理的最佳方法是什么?我目前使用 VS 2010 作为我的开发环境,并使用 SQL Server Data Tools (SSDT) 连接到外部 SQL Server 2008 R2 数据库。
我过去一直在做的是将 procs 保存到 .sql 文件并将这些文件保持在源代码控制之下。我确定一定有比这更有效的方法吗?我可以在 VS2010、SSDT 甚至生产机器上的 SQL Server 上安装扩展吗?
sql-server-2008 source-control sql-server stored-procedures version-control
我是一家小公司的一员,所以像往常一样负责许多不同的角色。最新的是为我们的 .NET Web 应用程序采购一个专用的 SQL Server 盒。我们在双 Xeon E5-2620(六核)2.00 GHz CPU 配置(共 12 核)上被引用,具有 32 GB 的 RAM。这使我们的磁盘阵列预算有限,该磁盘阵列基本上由 RAID 1 配置中的两个 2.5" SAS 300 GB 驱动器 (15k RPM) 组成。
我知道磁盘设置对于 SQL Server 来说是次优的,我真的很想推动 RAID 10,这样我们就可以将数据库、日志文件和 tempdb 放在他们自己的驱动器上。为了使这与我们的预算兼容,我应该考虑减少 CPU 内核的数量吗?或者我会得到更好的银行来保持核心并使用更少的驱动器,也许在双 RAID 1 设置中使用 4 个?
这是一些额外的统计数据
SQL Server 数据库倾向于大量读取到写入,可能分别为 80% 和 20%。当前的数据库大小目前约为10 GB 26 GB,以每月 250 MB 的速度增长。
目前在与 Web 服务器共享的单个四核 Xeon 机器上运行 SQL Server 2008 R2 Standard(RAID 1 中的 12 GB Ram、2 x 10k 300GB SAS 驱动器),希望迁移到 SQL Server …
我想将 SQL Server 数据库从与 Web 服务器的共享配置移动到它自己的专用框。我目前的预算允许我将 4 个磁盘放在一个阵列中,并带有一个热备用。我想扩展到 8 个以上的驱动器,但现在的成本有点超出我的预算(而且可能有点矫枉过正)。
所以我的问题是,当限制为 4 个磁盘时,SQL Server 2012 的最佳配置是什么?该数据库大约为 29 GB,并且每月增长大约 250-500 MB。数据库通常会提供 80% 的读取到 20% 的插入/更新/删除。
我从研究这个主题中了解到,我的选择如下:
我正在寻找一种解决方案,该解决方案可以为我提供合理的性能,但如果单个驱动器出现故障(我理解这在 SSD 中很常见),则不会消除阵列。
当前硬件 ------------------
HP ProLiant DL360 G7 1 x Xeon E5640 / 2.66 GHz - RAM 12 GB - RAID 1 中的 2 x 300GB 可插拔 SAS SFF 10,000 rpm 磁盘。
我正在使用 SQL Server 2012 SP2 使用BACKUP TO URL语句将我的事务日志直接备份到 Azure Blob 存储中。
然后我尝试验证我的交易日志,如下所示:
RESTORE VERIFYONLY FROM URL = 'https://mystore.blob.core.windows.net/logfile.trn'
WITH CREDENTIAL = 'azurecreds'
Run Code Online (Sandbox Code Playgroud)
该RESTORE VERIFYONLY操作对 Azure 中的文件进行了租借,我可以使用 Azure Management Studio 的 blob 浏览器查看该文件(我创建的最后 2 个文件没有运行 RESTORE VERIFYONLY)。
我可以使用 Azure Management Studio 手动中断租约,但我是否做错了RESTORE VERIFYONLY在文件上留下活动租约的问题?
我们在镜像中配置了两台 SQL 2012 数据库服务器,并带有用于自动故障转移的见证。
昨天主服务器遭遇硬盘降级,触发了故障转移,但是当辅助服务器成为原则时,我们开始看到一些 SPROC 执行时出现许多错误。
对象 '[sp_name]' 的定义自编译后已更改
我知道这可以通过运行sp_recompile新原则来解决,这将强制对所有 SPROC、函数和触发器进行重新编译。
这并不理想,因为它需要对故障转移进行手动干预。这是我可以通过修改配置解决的问题,还是已知的 SQL Server 错误?
我有一台运行 .NET Web 应用程序和 SQL Server 数据库(2008 标准)的服务器。我计划将数据库移动到单独的服务器上,但为了提供网络硬件,我想对 Web 应用程序和数据库之间的数据吞吐量进行基准测试。1433端口可以内部监控吗?如果是这样,是否有任何 Windows 2008 R2 原生工具可以做到这一点,或者我是否需要一些像 WireShark 这样的 3rd 方应用程序?我的连接字符串正在使用 引用数据库server=localhost,是否仍然可以访问 1433 以查看此端口上使用的带宽?
本质上,我试图确定在 Web 服务器和数据库服务器之间是否需要 Gbit 或 100 Mbit 连接。对此的任何想法将不胜感激。
7 月 8 日更新
我对上述内容进行了讨论,因为我意识到这在很大程度上无关紧要。出于某种原因,我认为 100 Mbit 和 1 Gbit 交换机之间的成本差异很大。只有cheapo 家庭用户交换机是100 Mbit。正如其他人指出的那样,Wireshark 不会在同一台机器上的 IIS 和 SQL 服务器之间获取活动。我现在正在安装一个 1Gbit 托管交换机,我将使用 Wireshark 或交换机上的内置监控来查看稍后会发生什么。我认为它不会接近硬件施加的物理传输限制。
sql-server ×6
hardware ×2
performance ×2
backup ×1
failover ×1
mirroring ×1
monitoring ×1
network ×1
restore ×1