数据库管理员

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

4
如何提高InnoDB DELETE性能?
因此,我有此审核表(跟踪数据库中任何表上的操作): CREATE TABLE `track_table` ( `id` int(16) unsigned NOT NULL, `userID` smallint(16) unsigned NOT NULL, `tableName` varchar(255) NOT NULL DEFAULT '', `tupleID` int(16) unsigned NOT NULL, `date_insert` datetime NOT NULL, `action` char(12) NOT NULL DEFAULT '', `className` varchar(255) NOT NULL, PRIMARY KEY (`id`), KEY `userID` (`userID`), KEY `tableID` (`tableName`,`tupleID`,`date_insert`), KEY …

2
可以同时在不同的表上运行两个DBCC INDEXDEFRAG命令吗?
我当前正在运行一个脚本,该脚本在SQL Server 2005数据库中的每个表上一次执行一个DBCC INDEXDEFRAG。由于空间限制和正常运行时间的要求,不能选择使用DBCC DBREINDEX而不是INDEXDEFRAG。 我注意到,某些表需要很长时间才能进行碎片整理。例如,如果我检查“ sys.dm_exec_requests”动态管理视图,则可以看到以下INDEXDEFRAG当前正在删除table_id为829610394的表的聚集索引: DBCC索引(0,829610394,1) 我知道碎片整理过程需要很长时间才能完成。撇开当前正在运行的脚本最终会对所有表进行碎片整理这一事实,在执行当前命令时在另一个表的聚集索引上手动运行另一个DBCC INDEXDEFRAG是否对我有什么危害?如果执行此操作,实际上是否会同时对两个表进行碎片整理?


2
如何停止/禁用PITR并安全清洁WAL网段?
我们的生产服务器在CentOS 5.2版(最终版)上运行PostgreSQL v8.2.3。 我们已经在生产服务器中设置了PITR。由于某些原因,设置PITR后,我们将无法管理和维护它。最终,我们的WAL存档驱动器(辅助驱动器)已满(100%使用),并且要存档的其他WAL存档段已累积在pg_xlog /目录本身中(在主驱动器中可用) PITR设置细节 有2个驱动器: 主驱动器(pgsql / data /目录驻留)为400 GB。 辅助驱动器(WAL存档)为300 GB。所有WAL归档文件都将写入此辅助驱动器。 现在,我们决定停止/禁用PITR。 我的问题是,在这种情况下,如何停止/禁用PITR并安全地清除两个驱动器中的所有WAL段? 推荐/建议的方式是什么?对此,专家的建议/想法/建议受到高度赞赏。

1
从MySQL Workbench创建外键时出错
我正在尝试将模式更改从MySQL Workbench同步到我的数据库。尝试创建外键时出现以下错误: Executing SQL script in server ERROR: Error 1005: Can't create table 'tomato.#sql-2730_1b8' (errno: 121) 这是它试图执行的语句: ALTER TABLE `tomato`.`ing_allergy_ingredient` ADD CONSTRAINT `fk_ai_allergy` FOREIGN KEY (`allergy_id` ) REFERENCES `tomato`.`ing_allergy` (`allergy_id` ) ON DELETE NO ACTION ON UPDATE NO ACTION 任何想法这个错误是什么意思?

5
有专业的全职PostgreSQL DBA吗?
我的工作是使用PostgreSQL作为数据库的JavaEE应用程序。尽管我们有生产服务器的系统管理员,该管理员还管理我们的数据库服务器,但是我们没有专职的DBA,这使我想知道是否有。我可以想象任何专职的DBA都可以专门与Oracle数据库一起工作。我是在忽略某些东西还是在假设没有专用的Postgres DBA时是正确的? PS:我只是出于好奇而问这个。 PPS:我想用DBA标记这个问题,但是显然这将是一个新标记。有人可以帮我吗?



2
在Google App Engine中,最有效的多对多联接模型是什么?
在BigTable的设计拒绝了许多标准的关系型模式的哲学的,明确非规范化宁愿到细微的小表的大主机。 问题所在的较大区域之一是对多对多联接的建模。 对这些联接建模的一种方法是违反第一范式,然后将所有有趣的数据放入db.ListProperty()中。尽管这具有从查询中进行搜索的能力,但我尚未探索搜索列表与提取另一个表的性能含义。 由于连接是不可能的,这是可以通过RelationshipProperties链接表。因此,只要付出足够的努力,就可以创建标准相交表(具有引用两个父表的联合主键的表)。有没有人探索过各种实现的性能影响? -编辑- 虽然文档中建议的“密钥列表”确实是实现此目的的一种方法,但我对该类和其他实现的性能和异常率感兴趣。创建公用密钥列表是否有用?重复付出的努力值得付出代价吗?有更好的方法吗?

1
小型微控制器的快速数据库
我使用的是PIC32,它是32位处理器,时钟频率为80 MIPS,可用RAM约为64-128KB。它将访问FAT32文件系统上的microSD卡(最大4 GB)。运行所有这些都可以推动它,但是我需要一个紧凑的数据库,该数据库可以轻松地移植到该平台上,并且要快速。有没有人有什么建议?

2
集群索引现在必须-为什么?
早些时候,关于是否(始终)参与/避免聚集索引的辩论/讨论对我来说不是结论性的。 好吧,我知道有时要结合适当的特定目的和上下文来使用它们。 SQL Azure数据库群集索引要求: “ SQL Azure不支持没有聚簇索引的表。表必须具有聚簇索引。如果创建的表没有聚簇约束,则必须先创建聚簇索引,然后才能对表进行插入操作” 不符合先前的结论,理由和解释。 在先前的解释中,我遗漏了没有任何例外地严格施加聚集索引的基本原理是什么?

1
没有WHERE子句的UPDATE是否会锁定PostgreSQL中的表?
整个表UPDATE(没有指定WHERE子句)是否在PostgreSQL中锁定了一个表?例如,它是否防止行被删除/插入? 例如,如果运行,是否 UPDATE t1 SET key = 'value' 可以t1在UPDATE执行过程中插入新行? 如果否,我UPDATE是否可以期望即使启动后出现的行也会更新?(键DEFAULT 'value'的定义中没有)

2
SQL Server的可序列化隔离级别是否锁定整个表
我和我的一位同事讨论了使用可序列化隔离级别的含义。他说它锁定了整个表,但是我不同意告诉他它有可能,但是它尝试应用范围锁,并且没有应用真正的序列化,如下所述:Serializable Isolation Level。 我在文档中也找不到“锁定整个表”的任何内容:SET TRANSACTION ISOLATION LEVEL。 该文档陈述了有关范围锁的许多信息,因此从理论上讲,您可以通过仅具有范围锁来锁定整个表,该范围锁可以锁定表中可能值的整个范围,但不会锁定表。 我在这里完全错了吗?它是否实际上锁定了整个表?

3
RAM或物理文件中的事务日志?
我是交易的初学者,只是有关交易日志的问题。我们知道在提交事务时,更改将写入事务日志,但是事务日志是否在RAM或物理文件中?如果它在RAM中并且发生系统故障时,显然RAM将被重新擦除,因此我们丢失了事务信息,那么如何恢复提交?

2
非常相似的查询,性能差异很大
我有两个非常相似的查询 第一个查询: SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' and a.TargetTypeId IN (1,2,3,4,5,6,7,8,9, 11,12,13,14,15,16,17,18,19, 21,22,23,24,25,26,27,28,29,30, 31,32,33,34,35,36,37,38,39, 41,42,43,44,45,46,47,48,49, 51,52,53,54,55,56,57,58,59, 61,62,63,64,65,66,67,68,69, 71,72,73,74,75,76,77,78,79) 结果:267479 计划:https://www.brentozar.com/pastetheplan/?id = BJWTtILyS 第二个查询: SELECT count(*) FROM Audits a JOIN AuditRelatedIds ari ON a.Id = ari.AuditId WHERE ari.RelatedId = '1DD87CF1-286B-409A-8C60-3FFEC394FDB1' …

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.