数据库管理员

希望提高数据库技能并向社区中的其他人学习的数据库专业人员的问答

1
-E启动选项和SSD
有没有人看到-E使用SSD时会产生影响的证据? 对于“旋转生锈”驱动器的影响毋庸置疑-但是SSD并没有真正受到随机I / O的困扰。我不知道该-E选项是否可能会损害性能。 在具有混合驱动器(SSD SAN,PCI SSD和传统SAN)的服务器上,SQL Server必须决定是否使用启动-E。我有一些经验证据表明该选项可能会损害性能,但是在考虑将其取消之前,我希望获得其他人的反馈。 我的设置使用标准的64K RAID条带,并且NTFS群集大小也为64K。


2
默认情况下关闭CHECK_POLICY
我们从SQL Server 2000迁移到SQL Server2005。我无法更改的客户端软件创建了一个没有选项的用户 CHECK_POLICY = OFF; 创建用户后,我必须运行命令 ALTER LOGIN username WITH CHECK_POLICY = OFF; 按照建议禁用该策略,我不能。 是否可以禁用CHECK_POLICY没有CREATE LOGIN用户创建的默认设置CHECK_POLICY = OFF?


3
使用SUM()两次不是最佳选择?
我知道我必须写SUM两次,如果我想在HAVING子句中使用它(否则要使用派生表): SELECT id, sum(hours) AS totalhours FROM mytable GROUP BY id HAVING sum(hours) > 50; 我现在的问题是,这是否不是最理想的。作为程序员,该查询看起来像数据库将两次计算总和。是这样,还是我应该依靠数据库引擎为我做的优化? 更新:对类似查询的解释: postgres=> explain select sum(counttodo) from orderline group by orderlineid having sum(counttodo) > 100; QUERY PLAN -------------------------------------------------------------------- HashAggregate (cost=1.31..1.54 rows=18 width=8) Filter: (sum(counttodo) > 100) -> Seq Scan on orderline (cost=0.00..1.18 rows=18 width=8) (3 …


1
多次创建和删除#SomeTable是“合法的”吗?
我已经将代码分类为“连贯的块”,可以一遍又一遍地插入较长的“配置脚本”中,而我使用的模式之一是: CREATE TABLE #WidgetSetting ( WidgetID bigint not null, Name nvarchar(100) not null, Value nvarchar(max) not null, CreateDate datetime not null ) INSERT VALUES MERGE TABLES DROP TABLE #WidgetSetting 但是现在SSMS抱怨到下次CREATE TABLE火灾时该对象已经存在。是什么赋予了? 我认为很明显,我将不得不在脚本开始时声明一次表,然后截断而不是删除,但是自然地,令人沮丧的是,无法仅删除表并再次使用相同的名称。

3
删除假设指数
过去,我以为我会使用针对集群索引的DROP INDEX语句和针对非集群索引的DROP STATISTICS语句删除假设索引。 我有一个数据库,其中充满了我想清除的DTA残留物;但是,当我尝试删除该对象时,总是收到一条错误消息,告诉我无法删除该对象,因为它不存在或您没有权限。我是服务器上的完整系统管理员,因此希望拥有执行任何操作的权利。 我已经尝试了DROP STATS和DROP INDEX语句,但是都给了我同样的错误。 有人删除过这些吗?我想念一个窍门吗? 附录 翻看一下,我只是注意到,如果我右击该对象,则“ Script As”和“ DELETE”选项均为灰色。

1
如何切碎.docx XML?
我正在尝试将xml(实际上是docx文件)导入到sql server 2008数据库。我几乎是XML编程的新手。我用谷歌搜索了很多,但是几乎所有的示例都带有简单的xml文件。这里的xml文件有点复杂(请参阅下文)。您能否给我一些想法,我应该如何为此XML创建表,以及应该在sql server中运行什么查询。我需要所有标签的值,例如w:p,w:pStyle,w:bookmarkStart,w:t标签等w:rsidP,w:rsidRDefault,w:rsidR <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <w:document xmlns:ve="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing" xmlns:w10="urn:schemas-microsoft-com:office:word" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:wne="http://schemas.microsoft.com/office/word/2006/wordml"> <w:body> <w:p w:rsidR="00EF42E0" w:rsidRDefault="00EF42E0" w:rsidP="00EF42E0"> <w:pPr><w:pStyle w:val="Heading1"/> </w:pPr><w:bookmarkStart w:id="0" w:name="_Toc212523610"/> <w:r> <w:t>Summary</w:t> </w:r> <w:bookmarkEnd w:id="0"/> </w:p> <w:p w:rsidR="00EF42E0" w:rsidRDefault="00EF42E0" w:rsidP="00EF42E0"><w:pPr><w:pStyle w:val="mainbodytext"/><w:ind w:right="-694"/><w:rPr><w:b/><w:bCs/></w:rPr></w:pPr><w:r><w:rPr><w:b/><w:bCs/></w:rPr><w:t>What is the Group Defined Practice for Integrity Management?</w:t></w:r></w:p> <w:p w:rsidR="00EF42E0" …

1
规范化数据库而不访问源数据?
我已经开始担任新角色,负责处理大量相关数据。我们所有这些数据的来源是从我们无权访问的数据库中提取的各种Excel转储。担任此职位的上一个人使用了大约十二个Excel文件来收集这些数据文件,对其进行操作并创建报告。 我已经开始将转储移至Access数据库。我注意到很多Excel数据都是相关的,应该将其标准化。我目前正在做的是为每个数据转储创建一个表,并将其导入Access,并使用许多查询来复制数十种数据操作和报告。 在我唯一的来源是Excel转储出仓库的情况下,对数据进行规范化还有好处吗? 当我无法更改转储发送给我的格式时,如何对数据进行规范化? 此外,我的计划(取决于预算)是从Access迁移到MS SQL数据库。
8 ms-access 

4
mysql复制成功,但是slave没有复制
我已经创建了mysql主从配置,并且一切正常。“显示主状态”;在奴隶上不显示任何错误。这是输出 Slave_IO_State: Waiting for master to send event Master_Host: 109.123.100.58 Master_User: replica Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 106 Relay_Log_File: relay-bin.000001 Relay_Log_Pos: 4 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 106 Relay_Log_Space: 106 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 …


2
数据库查询优化器是否意识到存储性能差异?
据我了解,SQL Server(或其他任何RDBMS)中的查询优化器并不了解数据库下面存储的性能,并且会像所有存储具有相同的成本一样做出决策。这是否准确,或者是否考虑了一些有关存储性能的知识? 在一个完全人为的示例中,假设我的表行以瞬时访问时间存储在SAN中的SSD驱动器上,其中索引存储在极度超载的SAS驱动器上,从而导致磁盘饱和和恒定的磁盘队列。当RDBMS生成执行计划时,是否比索引操作更可能支持表扫描(或者可能是瘦索引和关联的表查找,而不是覆盖索引,因为它在SAS磁盘上的IO更少)? 我怀疑答案是肯定的,“优化器不会聪明甚至不会意识到磁盘性能”,但是我只是想看看那里是否有人肯定知道。我正在使用SQL Server,但对任何数据库系统都感兴趣。

2
当物理事务日志文件是镜像中的主体时,如何缩小物理事务日志文件?
我们在周末设置数据库镜像,但是忘记重新启用备份事务日志的作业。今天早上我来的时候,事务日志已经膨胀到58GB,并占用了大部分驱动器空间。 我将事务日志手动备份到磁盘以使数据库再次运行,但是运行DBCC SHRINKFILE似乎并没有减小事务日志文件的物理大小。 DBCC SHRINKFILE (N'MyDatabaseName_Log', 1000) 如果我使用以下命令查看日志使用情况 DBCC SQLPERF(LOGSPACE) 我可以看到仅使用了当前日志的22% 数据库名称日志大小(MB)使用的日志空间(%)状态 MyDatabaseName 55440.87 22.38189 0 如果我log_reuse_wait_desc在sys.databses中签出,则看到的唯一记录是DATABASE_MIRRORING,因此我猜测镜像在为什么日志文件的物理大小不会缩小的过程中发挥了作用? SELECT log_reuse_wait_desc FROM sys.databases WHERE name = N'MyDatabaseName'; 我还注意到我的主要数据库镜像状态为Suspended,并且尝试立即恢复它失败,并出现以下错误: 数据库'MyDatabaseName'的远程镜像伙伴遇到错误5149,状态1,严重性25。数据库镜像已被挂起。解决远程服务器上的错误并恢复镜像,或者删除镜像并重新建立镜像服务器实例。 镜像服务器上的错误日志也包含此错误,但是还包含有关日志文件驱动器已满的错误 尝试扩展物理文件时,“修改文件”遇到操作系统错误112(磁盘上没有足够的空间。)。 和 F:\ Databaselogs \ MyDatabaseName_1.ldf:遇到操作系统错误112(磁盘上没有足够的空间。)。 主体服务器在日志文件驱动器上有60GB(此处托管了其他数据库),而镜像服务器只有45GB。 备份日志文件使数据库再次可用,但是我还想减小磁盘上物理日志文件的大小,并恢复镜像。 如何在不损害镜像或备份链的情况下缩小物理事务日志文件的大小? 我正在运行SQL Server 2005

1
启动/停止MySQL
我正在寻求帮助,以了解执行以下命令行时会发生什么: root@prodn$ service mysqld stop 是的,它关闭了MySQL服务器,因此直到再次启动该服务后,对它的访问不再可用。但是,更具体地说,停止服务时还会发生其他情况吗?请原谅我的新手,但是当mysqld重新启动时,是否表示日志已刷新,部分内存已释放,缓存已清空等? 我问的原因如下: 我们的数据仓库数据库是MySQL数据库,在过去的4个月中,平均花费了8.5个小时。 上星期三,我停止了mysql服务,然后在30分钟后重新启动它。从那以后,我开始注意到整体性能有了巨大的提高 -SELECT / INSERT / UPDATE / DELETE流程更加高效。DW在差不多4个小时前完成了相同数量的数据行 但是,随着时间的流逝,完成时间会增加15-20分钟。因此,我怀疑我可能必须每周重新启动该服务。 有这种行为的解释吗?我不知道还有什么其他问题,但是很高兴知道mysqld服务重启时会发生什么。 谁能对此有所启发?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.