数据库管理员

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

1
PostgreSQL中的多个主键
我有下表： CREATE TABLE word( word CHARACTER VARYING NOT NULL, id BIGINT NOT NULL, repeat INTEGER NOT NULL ); ALTER TABLE public.word OWNER TO postgres; ALTER TABLE ONLY word ADD CONSTRAINT "ID_PKEY" PRIMARY KEY (word,id); 当我尝试使用以下命令还原它时： psql -U postgres -h localhost -d word -f word.sql 它给了我这个错误： 不允许表“ word”使用多个主键 如何在postgres中使用多个主键？
3
如果两个过程尝试同时同时刷新材料视图，会发生什么？
根据文档： 同步刷新实例化视图，而不会锁定实例化视图上的并发选择。（...） ...其他内容... 即使使用此选项，一次也只能针对任何 一个实例化视图运行一次REFRESH。 我有一个功能，可以检查上次刷新时间以进行材料视图，如果超过60秒，它将刷新它。 但是，如果我尝试同时从两个单独的进程中刷新实例化视图，将会发生什么？他们会排队还是会引发错误？ 有没有一种方法可以检测何时刷新了材料视图，因此避免触摸它？ 目前，我在刷新之前将表记录填充（设置refreshing为true），然后false在过程完成时将其设置为。 EXECUTE 'INSERT INTO refresh_status (last_update, refreshing) VALUES (clock_timestamp(), true) RETURNING id') INTO refresh_id; EXECUTE 'REFRESH MATERIALIZED VIEW CONCURRENTLY my_mat_view'; EXECUTE 'UPDATE refresh_status SET refreshing=false WHERE id=$1' USING refresh_id; 然后，每当我调用此过程时，我都会检查最新过程last_update及其refreshing值。如果refreshing为true，则不要尝试刷新实例化视图。 EXECUTE 'SELECT extract(epoch FROM now() - (last_update))::integer, refreshing FROM refresh_status ORDER BY …
6
操作系统返回错误21（设备未准备好。）
每次重新启动Windows时，对于某些数据库，都会出现此错误： 操作系统返回错误21（设备未准备好。） 我检查了磁盘chkdsk /r-没有坏扇区。 我执行DBCC CHECKDB没有错误： *(CHECKDB found 0 allocation errors and 0 consistency errors in database)* 如果我重新启动SQL Server，错误将消失。 Windows 10和SQL Server 2016 Express。
6
重建非常大的主键索引
我有一个托管在Azure上的SQL数据库。问题在于大小已失控，我可以在主键聚集索引中看到多达99％的碎片。 我能够使用online=onoption 重建所有其他索引，并且不会影响性能。PK聚簇索引之一的大小大于200GB，并且为此REBUILD...WITH (ONLINE=ON)导致锁定。 实际上，确实有来自所有时区的用户都在访问该网站，因此，我找不到可以离线重建索引的时间。 在不造成站点停机的情况下重建大型索引的最佳策略是什么？ 我相信重组将无济于事，因为碎片化率为99％。问题在于该表即使在线也被锁定。主要问题是索引大于200GB。主键是一个整数。
1
在PostgreSQL中取消（AUTO）VACUUM进程是否会使所有工作无效？
在某些场合，并作出巨大的后update，insert或delete从一个表，我已经开始了VACUUM FULL ANALYZE，以确保DB没有得到太臃肿。在生产数据库中进行操作使我发现这不是一个好主意，因为我可能会长时间阻塞该表。因此，我取消了此过程，可能只是尝试了一下VACUUM（未完成），或者AUTOVACUUM稍后再做任何可以做的事情。 问题是：如果我在中途停止VACUUM或AUTOVACUUM，是否已经完成所有处理？ 例如，如果VACUUM已经找到1 M死行而我停止了，所有这些信息会丢失吗？VACUUM是否以完全事务性的方式工作（“全部或全部”，就像很多PostgreSQL进程一样）？ 如果可以安全地中断VACUUM而不会丢失所有工作，那么有什么方法可以使vacuum工作逐步进行？[工作100毫秒，停止，等待10毫秒，以便不阻塞世界其他地方...依此类推]。我知道您可以通过调整自动真空参数来完成部分操作，但是我正在考虑能够以编程方式控制此操作，以便能够在特定时间/特定条件下执行此操作。 注意：在这种情况下，停止/取消/终止进程意味着： 如果使用pgAdmin，请按“取消查询”按钮。 如果以编程方式工作，请调用pg_cancel_backend（）。 我认为两者是等效的。我还没有使用过任何shell /系统级的kill命令。
2
使用来自SQL Server中另一个表的值更新表
我的数据库中有2个表。 表格1 ------------------------------------------------------------------------- | name | family | phone | email | gender | phone2 | address | birthdate | ------------------------------------------------------------------------- 表＃2 ----------------------------------------- | gender | address | phone | birthdate | ----------------------------------------- 在表＃1的列地址和PHONE2是空的和列性别和生日的值是相同的表＃2。 我怎样才能读取表＃2和更新数据的地址和PHONE2表＃1的值从表＃2 的地址和电话列时，性别和出生日期是各行中的一样吗？ 例如：这是表＃1中的一些数据 ------------------------------------------------------------------------- | name | family | phone | email | gender | phone2 …
1
为什么这些类似的查询使用不同的优化阶段（事务处理与快速计划）？
此连接项中的示例代码 显示一个错误 SELECT COUNT(*) FROM dbo.my_splitter_1('2') L1 INNER JOIN dbo.my_splitter_1('') L2 ON L1.csv_item = L2.csv_item 返回正确的结果。但是以下内容返回的结果不正确（2014年使用新的Cardinality Estimator） SELECT (SELECT COUNT(*) FROM dbo.my_splitter_1('2') L1 INNER JOIN dbo.my_splitter_1('') L2 ON L1.csv_item = L2.csv_item) 因为它错误地将L2的结果加载到公共子表达式假脱机中，然后重播L1结果的结果。 我对为什么两个查询之间的行为差​​异感到好奇。跟踪标志8675显示工作的一个进入search(0) - transaction processing而失败的一个进入search(1) - quick plan。 因此，我认为其他转换规则的可用性是行为差异的背后原因（例如，禁用BuildGbApply或GenGbApplySimple似乎可以解决此问题）。 但是，为什么针对这些非常相似的查询的两个计划会遇到不同的优化阶段？根据我的阅读search (0)，至少需要三个表，并且在第一个示例中肯定不满足该条件。
3
进行未提交的SET事务隔离级别的好处
我SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED在大多数常规SQL查询中使用了大多数方法，主要是因为这是在最初学习该语言时钻到我身上的。 根据我的理解，此隔离级别的行为方式与WITH (NO LOCK)我曾经倾向于使用的方式相同SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。 有没有时间我应该WITH (NO LOCK)用完SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。 是否 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED阻止其他用户被锁定在我正在读取的表之外？ 如果 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED用于停止锁，但是我仅在读取数据，那么使用它有什么意义？只是系统密集型查询会生成锁吗？在运行将在5到10秒内返回的查询时，是否值得使用它？ 我被告知不要 SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED在读取将用于更新的数据时使用，大概是为了避免更新脏数据。这是唯一的原因吗？ 对于我正在处理的数据库类型，有一个生产和测试环境。我们很少会查询生产环境，但是在需要时，通常会SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED在查询中使用它。我知道这样做可能会导致脏读。除了接收可能不会最终提交给数据库的数据（因此将我的结果排除在外）之外，还有哪些其他类型的“脏读”是可能的？ 很抱歉出现大量问题。
2
在将文件添加到tempdb的上下文中，热点是什么？
我试图找出是否有可能在不重新启动SQL Server服务的情况下将tempdb文件添加到SQL Server。我在数据库管理员那里看到了这个答案： Tempdb添加文件需要重新启动 一个答案指出： 添加-无需中断。尽管正如Microsoft的Sean指出的那样，SQL将更喜欢使用填充较低的文件。如果您要从1个数据文件开始添加更多数据，则SQL会在一段时间内使用新数据文件，但是您的性能不会比仅拥有一个文件更糟。但是，如果您已经有2个以上并添加一个以上，则它将在新的1个热点上出现并降低性能。 但是，有一条评论警告以下内容： 我将在“添加”部分添加一个附录：“添加：不，但是您很可能会失衡，所以您会发现热点，这会使情况变得更糟。” 我有关于该评论的以下问题，但被指示在我自己的新问题（此问题）中提出这些问题，而不是通过对该问题的答案中的评论来询问评论者。 特别： 什么是热点？（我通过Google获得了一些信息，但未详细添加文件后在tempdb上进行热点时会发生什么情况） 热点问题会使tempdb变得更糟吗？ 数据库中哪些特定的事情会变得更糟？
4
将NVARCHAR（4000）列快速更改为NVARCHAR（260）
我在使用非常大的内存授予时遇到了一个性能问题，需要处理两NVARCHAR(4000)列该表。问题是这些列永远不会大于NVARCHAR(260)。 使用 ALTER TABLE [table] ALTER COLUMN [col] NVARCHAR(260) NULL 导致SQL Server重写整个表（并在日志空间中使用2倍的表大小），这是数十亿行，只能更改任何内容，这是不可行的。增大列宽不会出现此问题，但是减小它确实会出现此问题。 我尝试创建约束，CHECK (DATALENGTH([col]) <= 520)或者CHECK (LEN([col]) <= 260)SQL Server仍然决定重新编写整个表。 有什么方法可以将列数据类型更改为仅元数据操作？无需重写整个表？我正在使用SQL Server 2017（14.0.2027.2和14.0.3192.2）。 这是用于重现的示例DDL表： CREATE TABLE [table]( id INT IDENTITY(1,1) NOT NULL, [col] NVARCHAR(4000) NULL, CONSTRAINT [PK_test] PRIMARY KEY CLUSTERED (id ASC) ); 然后运行ALTER。
3
将大表上的更改列速度提高到NON NULL
我最近在一个表中添加了一个可为NULL的位列，该表具有近5亿行。列上没有默认值，但是所有插入都将值指定为0或1，并且我运行了一次例程，将0或1分配给所有现有行（小批量更新行）。现在，每一行在该列中应具有0或1。 我想使bit列不可为空，但是当我尝试通过via进行操作时ALTER TABLE t1 ALTER COLUMN c1 bit not null，它开始运行了3分钟，并且我停止了它，因为它阻止了对表的所有读取，并且我怀疑它将花费很长时间才能完成。可能不会花费太长时间，但是我不能冒太多不可用的风险。回滚本身花费了6分钟。 您对我如何使该列不可为空而不可能花费数小时才能完成有什么建议？ 另外，有什么方法可以估算ALTER TABLE ALTER COLUMN我开始然后取消的语句需要多长时间？ 我正在使用SQL Server 2017 Web Edition。
3
IndexOptimize之后查询和更新非常慢
数据库SQL Server 2017 Enterprise CU16 14.0.3076.1 最近，我们尝试从默认的“索引重建”维护作业切换到Ola Hallengren IndexOptimize。默认的索引重建作业已经运行了几个月，没有任何问题，并且查询和更新在可接受的执行时间内正常工作。在IndexOptimize数据库上运行后： EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 5, @FragmentationLevel2 = 30, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y' 性能极度下降。使用100ms之前的一条更新语句IndexOptimize之后（使用相同的计划）花费了78.000ms，并且查询的执行情况也差了几个数量级。 由于这仍然是一个测试数据库（我们正在从Oracle迁移生产系统），因此我们恢复为备份并禁用IndexOptimize，一切恢复正常。 但是，我们想了解与可能导致这种极端性能下降IndexOptimize的“正常” Index Rebuild行为有何不同，以确保一旦投入生产就可以避免这种情况。关于寻找什么的任何建议将不胜感激。 update语句执行速度慢时的执行计划。即 在IndexOptimize 实际执行计划之后（尽快推出） 我还没发现差异。 快速计划相同的查询 实际执行计划
1
SQL扩展事件会话，用于死锁检测
有没有办法增加<inputbuf>死锁扩展事件会话捕获的死锁XML中元素的大小？ 我们希望看到完整的查询，以帮助在应用程序代码中查明问题。 似乎仅限于1024个字符+/-。可以增加吗？ 请参阅下面的XML示例。您可以看到<inputbuf>元素的查询文本在选择列表的中间被截断了： <deadlock> <victim-list> <victimProcess id="processc9c0829848" /> </victim-list> <process-list> <process id="processc9c0829848" taskpriority="0" logused="0" waitresource="PAGE: 5:1:40600276 " waittime="696" ownerId="255115931225" transactionname="SELECT" lasttranstarted="2019-04-24T09:29:25.950" XDES="0xc8dfa8da40" lockMode="S" schedulerid="13" kpid="8480" status="suspended" spid="245" sbid="2" ecid="0" priority="0" trancount="0" lastbatchstarted="2019-04-24T09:29:25.950" lastbatchcompleted="2019-04-24T09:29:25.950" lastattention="1900-01-01T00:00:00.950" clientapp="EntityFramework" hostname="MSR-PRD-BDB02" hostpid="43440" loginname="IUSR_BuildDB" isolationlevel="read committed (2)" xactid="255115931225" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056"> <executionStack> <frame procname="adhoc" …
1
这是服务器过载的症状吗？
我一直在尝试诊断应用程序中的运行缓慢。为此，我记录了SQL Server 扩展事件。 对于这个问题，我正在研究一个特定的存储过程。 但是有一组核心的存储过程，这些存储过程同样可以用作“一对一调查” 而且每当我手动运行其中一个存储过程时，它总是运行很快 如果用户再次尝试：它将运行很快。 存储过程的执行时间千差万别。此存储过程的许多执行都在<1s内返回： 而对于“快速”存储桶，它远小于1s。实际上大约是90毫秒： 但是有很多用户需要等待2s，3s，4s秒。有些必须等待12s，13s，14s。然后就是真正的可怜人，他们必须等待22、23、24秒。 30秒后，客户端应用程序放弃，中止查询，用户不得不等待30秒。 相关查找因果关系 所以我尝试关联： 持续时间与逻辑读取 持续时间与物理读取 持续时间与CPU时间 而且似乎没有任何关联。似乎没有原因 持续时间与逻辑读取：不管是逻辑读取还是多次读取，持续时间仍在剧烈波动： 持续时间与物理读取：即使查询不是从缓存中进行的，并且需要大量物理读取，它也不会影响持续时间： duration vs cpu time：查询所用的CPU时间为0s，还是CPU的完整时间为2.5s，则持续时间具有相同的可变性： 奖励：我注意到持续时间v物理读取和持续时间v CPU时间看起来非常相似。如果我尝试将CPU时间与“物理读取”相关联，就证明了这一点： 原来很多I / O占用了CPU。谁知道！ 因此，如果执行查询的行为没有什么可以解释执行时间的差异，这是否暗示它与CPU或硬盘驱动器无关？ 如果CPU或硬盘驱动器是瓶颈；难道不是瓶颈吗？ 如果我们假设是CPU是瓶颈，那么，该服务器的CPU电源不足： 那么执行使用更多CPU时间的时间不会更长吗？ 因为他们必须使用过载的CPU与他人一起完成？ 对于硬盘驱动器类似。如果我们假设硬盘驱动器是瓶颈；硬盘驱动器对此服务器没有足够的随机吞吐量： 那么执行更多物理读取操作不会花费更长的时间吗？ 因为他们必须使用过载的硬盘I / O与其他人一起完成？ 存储过程本身既不执行也不要求任何写操作。 通常它返回0行（90％）。 有时它将返回1行（7％）。 很少会返回2行（1.4％）。 在最坏的情况下，它已返回2行以上（一次返回12行） 因此，这并不像在返回疯狂的数据量。 服务器CPU使用率 服务器的处理器使用率平均约为1.8％，偶尔会激增至18％-因此看来CPU负载似乎不是问题： 因此，服务器CPU似乎没有过载。 但是服务器是虚拟的... 宇宙之外的东西？ 我能想象的唯一剩下的就是服务器领域之外的东西。 …
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.