对于我的客户，我有时会在他们的实时数据库中工作，以解决他们自己创建的问题，或者修复产品缺陷所造成的不良数据。就像Unix的root访问一样，这很危险。我应该提前学习什么课程？

在操作实时数据时要注意的第一件事是什么？

解决方案

对副本进行更改，并在满意后将其应用于实时环境。

始终确保UPDATE和DELETE具有正确的WHERE子句。

确保删除记录时指定了where子句。

始终首先测试除选择之外的所有查询，以确保对开发数据具有正确的影响。

在开始之前备份或者转储数据库。

要补充@Wayne所说的内容，请在表名之前的DELETE或者UPDATE语句中写上WHERE。

首先进行备份：无论如何，它应该是系统管理的第一法则

编辑：结合其他人说的话，确保更新具有适当的WHERE子句。

理想情况下，绝不应该更改实时数据库(除了INSERT和基本维护之外)。更改活动数据库的结构尤其充满了潜在的不良业障。

备份数据。了解到这是一种定期使用客户数据库的困难方式。

也许考虑根本不使用任何删除或者删除。或者降低用户权限，以便只有特殊的数据库用户才能删除/删除内容。

始终添加using子句。

如果我们使用的是Oracle或者其他支持它的数据库，请在执行COMMIT之前验证更改。

BEGIN TRANSACTION;

这样，我们可以在出错后回滚。

要回答我自己的问题：

编写更新语句时，请无序写入。

• 写UPDATE [table-name]
• 写" WHERE [conditions]"
• 回去写SET [columns-and-values]

在说出要更改的值之前，选择要更新的行比按其他顺序执行要安全得多。这使得`update person set email ='[email protected]'不可能位于查询窗口中，可以通过错位的按键来运行，也可以弄乱表中的每一行。

编辑：正如其他人所说，在编写DELETE之前，为删除内容编写WHERE子句。

除非我们处于BEGIN TRAN t1中，否则请勿进行更新-不在dev数据库中，不在生产环境中，不在任何地方。切勿在注释外部运行COMMIT TRAN t1-始终键入

--COMMIT TRAN t1

然后选择该语句以运行它。 (很明显，这仅适用于GUI查询客户端。)如果我们执行这些操作，则成为它们的第二习惯，并且我们几乎不会在任何时间丢失。

我实际上有一个"更新"宏来键入此内容。我总是将其粘贴以设置我的更新。我们可以为删除和插入创建类似的内容。

begin tran t1
update 
set 
where 
rollback tran t1
--commit tran t1

确保查询中指定了" WHERE"参数

我曾经在进行复杂的更新时中途分散注意力，并尽早完成了查询，却忘记了" where"子句。然后我有了那种下沉的感觉，看着半秒钟的查询持续了3秒钟。之后花了几个小时清理客户数据，这是相当不错的一课！

结果是，当我在实时数据库上工作时，我的查询结构如下：

UPDATE my_table WHERE condition = true;

然后返回并放入列等进行更新。需要更长的时间来编写，但是大大减少了我再次犯同样的错误的机会！

通常，在执行UPDATE或者DELETE之前，我要编写等效的SELECT。

• 检查，重新检查并再次检查正在执行更新的任何陈述。即使我们认为我们只是在进行简单的单列更新，迟早我们也不会喝足够的咖啡，而忘记了" where"子句，从而破坏了整个表。

我发现其他一些有用的东西：

• 如果使用MySQL，请启用安全更新
• 如果我们有DBA，请要求他们这样做。

我发现这三件事使我免受任何严重伤害。

首先在开发环境中进行完全相同的更新，以确保其正常工作。

这些年来，我已经学到了三件事：

首先，如果我们要对实时数据进行更新或者删除，请首先使用要使用的WHERE子句编写一个SELECT查询。确保它可以正常工作。确保它是正确的。然后将UPDATE / DELETE语句放在已知的工作WHERE子句之前。

你永远都不想拥有

DELETE FROM Customers

坐在查询分析器中，等待我们编写WHERE子句...意外地单击"执行"，我们刚刚杀死了Customer表。哎呀。

另外，根据平台，了解如何对表进行快速的"脏"备份。在SQL Server 2005中，

SELECT *
INTO CustomerBackup200810032034
FROM Customer

会将整个客户表中的每一行复制到一个名为CustomerBackup200810032034的新表中，完成更新并确保一切正常后，可以将其删除。如果发生最坏的情况，那么从该表中还原丢失的数据要比尝试从磁盘或者磁带还原昨晚的备份要容易得多。

最后，请警惕级联删除，以摆脱我们不打算删除的内容，然后在修改任何内容之前检查表的关系和键约束。

• 没有人想要备份，但所有人都在哭泣以求恢复
• 使用外键引用创建数据库，因为我们应该：
• 使自己尽可能难以更新/删除数据并破坏结构完整性/
• 如果可能，请在必须永久保存更改的系统上运行(即，在修复数据库时停用自动提交)
• 尝试确定问题的类别，以便我们了解如何轻松解决问题
• 获得在数据库中播放备份的例程，始终在测试服务器上拥有第二个数据库，以便我们可以在该数据库上进行工作
• 因为请记住：如果某件事完全失败，则需要尽可能快地重新启动并运行

好吧，这就是我现在能想到的。采取大胆的段落，我们会发现对我来说最重要的是第一。 ;-)

如果它支持，请在数据库IDE中将其关闭。我一直都在Oracle SQL Developer中将其关闭。

例如，我创建这样的SQL

--Update P Set
--Select ID, Name as OldName, 
    Name='Jones'
From Person P
Where ID = 1000

我突出显示了从最后到Select的文本，然后运行该SQL。一旦我确认它正在提取我要更新的记录，就按下上移键以突出显示Update语句并运行它。

请注意，我使用了别名。我从不显式更新表名。我总是使用别名。

如果我结合事务和回滚/提交来执行此操作，那么我真的非常安全。

我没看过但我经常做的一件事是：备份要更新的表。我通过拥有一个数据库来保存这些备份来做到这一点。然后我可以写：

select *
  into MyBackupDb..PeterTableName2008_09_28BeforeABigUpdate

这样一来，从错误中恢复的速度会大大加快(当不进行完全恢复时)。

数据应始终通过脚本进行部署，以使其实时运行，脚本可以根据需要进行多次演练，以使其在开发人员中正确使用。当脚本具有相关数据才能在dev上正确运行时，请适当地暂存它-如果我们确实要小心，就无法逃避此步骤。

• 如果可能的话，要求与某人配对
• 在按Enter键之前始终计数到3(如果单独使用，因为这会激怒伴侣！)

我使用实时数据库时要小心的第一方法？别碰它:)

备份可以消除对数据库造成的损害，但是在这段时间内，我们仍然可能会带来负面影响。

无论我们认为所使用的脚本有多扎实，都需要在测试周期中运行它。即使"测试周期"意味着要针对自己的数据库实例运行脚本，也请确保执行此操作。在生产环境中引入缺陷比在生产环境中引入缺陷要好得多。

我的规则(作为应用程序开发人员)：不要碰它！那就是训练有素的DBA的目的。哎呀，我什至都不想要触摸它。 :)

检查两次，提交一次！

如果要使用脚本更新数据库，请始终确保在脚本的开头放置一个或者两个断点，以防万一我意外地碰到了运行/执行。

1当我们知道需要更新或者插入记录时，请务必在打开连接之前创建备份。

2在编写更新语句时，请始终先写入WHERE子句，然后将光标移回该行的开头并写入字段更新部分。

3＃2的where语句应使用select语句进行检查。

在更新之前，我将建议我们进行BEGIN TRAN，只是不要忘记实际执行COMMIT；如果我们保留未提交的交易，可能会造成同样多的损失。在更新过程中，请勿因电话，同事，午餐等而分心，否则我们会发现其他所有人都被锁定，直到我们提交或者回滚为止。

去购买Apex SQL日志。如果我们意识到自己确实搞砸了，或者即使是别人，也可以使用日志来撤消更改。

在Query Analyzer中写出即席查询时，我总是注释掉所有破坏性查询(插入，更新，删除，删除，更改)。这样，运行它们的唯一方法是突出显示它们，而不选择注释的部分，然后按F5.

如前所述，我还认为这是一个好主意，首先使用select编写where语句，并确保我们正在更改正确的数据。

• 始终在更改之前进行备份。
• 始终通过脚本制作mod(例如，ALTER TABLE)。
• 始终通过存储过程修改数据(例如DELETE)。

备份的开发人员请确保要应用的更改/修复来自脚本。处理实时数据时，胖而笨拙的手指没有位置。如果可以，请等待维护窗口应用并回滚。

如果我们迫不及待想要在快照，备份之后立即应用，请确保eveyrone理解了在上一次快照与应用"修复"的时间(如果无法解决)之间进行前滚更改时可能要进行的工作。

创建一个只读用户(或者让DBA这样做)，并且仅使用该用户查看数据库。向架构添加适当的权限，以便我们可以查看存储过程/视图/触发器/等的内容。但没有能力更改它们。

每种环境使用不同的颜色：我们已经设置了PL \ SQL开发人员(适用于Oracle的IDE)，因此，当我们登录到生产数据库时，所有窗口均为亮红色。有些甚至还为开发和测试分配了不同的颜色。

就像对任何类型的代码进行更改一样，使用相同的过程对简单的SQL数据修复进行质量检查。我们的工作包括致力于CVS，拥有并执行成文的测试计划，进行代码审查以及进行变更控制流程(其中，管理部门的各个成员和高级运营工程师审查并签署变更)。

我们对所有普通的SQL数据修复都执行此操作，即使是简单的SQL数据修复，唯一的例外是需要采取某些措施解决生产中的重要问题(例如阻止所有客户登录)，在这种情况下，我们确保有成对的尽可能地注意工作(通常在一个工作站周围有3-4个人，他们所有人都可以否决任何行动)。

除了在进行任何破坏性更改之前对数据库进行备份之外，有时我发现有用的另一种技巧是，如果我知道我希望通过所做的任何更改来更改记录的确切数量，则添加一个limit子句：

从id = 5限制1的客户中删除；

" id"可能是唯一索引，我知道只有一行与我的where子句匹配，但是限制是防止意外误输入错误数据的添加保护层。我已经习惯了先键入此部分，以期进一步防止意外的击键。我从"删除限制1"开始，然后返回并添加其他内容。

如果我们使用的是SQL Server 2005及更高版本，则可以创建数据库快照，该快照将使我们回滚对快照时间点所做的任何更改。

当仅更新/删除一条记录时，mysql允许我们在末尾放置" LIMIT 1"，因此即使WHEN子句错误，也只会损坏一条记录。

我经常不得不在实时生产站点上插入，更新或者删除数据(作为数据分析师，这可能占我工作的40％)。在大多数情况下，它是通过自动DTS或者SSIS软件包进行的。但是，当主要客户驱动的变更发生时(例如对销售人员进行重组)，我们也是必须解决问题记录或者更新生产的人员。有时，问题是由于代码中的错误引起的，但通常是由于客户端对文件所做的奇怪操作或者用户为避免我们为解决问题而浪费时间而弄乱的事情所致，或者是由于他们希望规避常规错误而导致的。只需一个快速简单的更改即可完成该过程！(用户注意-请不要尝试手动修复通常通过自动化过程完成的事情，我们不知道该过程还会做什么！有时我们没有奢侈地先在开发人员上测试脚本，因为需要修复的内容不在开发人员上。

我的规则：永远不要将数据直接从文件插入到生产表中。始终将其带入工作表中，以便我们可以首先查看它。进行检查，以确保文件中如果有不良数据，则该过程将失败，然后再执行插入生产数据的最后一步。首先清理数据。

如果必须删除大量记录，那么如果我们首先将这些记录选择到工作表中，则可以节省时间。然后进行删除。这样，如果出现问题，恢复起来就容易得多。如果我们有审核表，请知道如何快速从中恢复数据。同样，如果出现问题，从审核表中恢复比从磁带备份中恢复要快得多。

我写这样的删除语句：

开始翻译

删除一个

--select(列出重要字段以在此处查看)

从table1 a中，其中field1 ='x'

--rollback tran

-提交tran

请注意与此有关的几件事。首先，通过使用别名，我不会仅通过突出显示一行并运行代码来意外删除整个表。通过在表的同一行上启动where子句，我不太可能错过突出显示它的可能性。如果我有联接，我将确保每一行都在一个除非代码转到下一行才起作用的地方结束。同样，这可以确保我们得到的是错误而不是" oopsie"。始终先运行select并记下受影响的记录数(并查看数据以确保它看起来像正确的记录！)然后，除非在运行实际删除时记录数正确，否则不要提交。是的，在单独的行上开始where是更好的做法，结束删除的每一行更安全，这样除非突出显示整个查询，否则它不会运行。

更新遵循相似的规则。

我总是想到运行意外删除(或者插入或者更新)的危险。

我总是在它们之后添加" where 1 = 2"，直到准备好扣动扳机为止。

如果我们使用的是oracle 10 / 11g ...闪回

http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm

它基本上维护着一个撤消日志的滑动窗口，该窗口可以按时间或者命名标记进行引用。它使死掉的事情变得很简单，只需几分钟即可撤消数天的更改。而无需关闭数据库。

让DBA完成工作。来自开发背景，我不希望/不需要/应该访问任何人的实时数据库。对我来说，这等效于在DAL中让DBA修复编码问题，只是因为它的标题中包含"数据库"。 :-)

如果我们使用的是SQL Server 2005+ Management Studio，则可以打开"隐式事务"。

• 每当连接到实时数据库时，我总是喜欢有人看着我。
• 将生产数据库的最新副本存储在某个位置。这通常会排除我们查询生产数据库的需要。
• 如果我们必须对正在运行的数据库执行任何操作。记录下来，并以管理员可用的编码功能添加修复程序。这样，我们就少了一个将查询工具指向数据库的借口。

我在一次采访中了解到了这一点，并认为这是一个好主意。

Begin Transaction
    Delete from foo where FooID = 100
IF @@RowCount <> 1 Begin
    Rollback Transaction
End

每当我打开与PROD的连接或者切换到PROD数据上下文时，我总是做的第一件事是在活动的工作代码块之前和之后添加此注释：

-- PROD -- PROD -- PROD -- PROD -- PROD -- PROD --

有时候，当我的拇指放在Alt键上并且中指位于" X"键的一半时，我注意到了这一点。 ew！

如果我们使用的是Microsoft SQL Server Management Studio 2008，则可以在执行查询时在信息窗口中指定要使用的颜色(在Sql Query Editor的底部)

在连接提示上，选择选项>使用自定义颜色，然后选择红色进行生产。

切勿设计任何具有级联删除的数据库。他们是邪恶的。如果确实在FK上进行了级联删除，则在使用delete语句删除一行时，我们将永远不知道将删除其他引用表中的多少行。

就是说，我们不能对其他人的所作所为承担任何责任。我总是这样做：
1.将数据库复制到本地安装的数据库(使用转储)。只需告诉管理层，如果我们在本地计算机上无法拥有完整数据库的副本，则我们拒绝工作。
2.使脚本在本地数据库上工作，一遍又一遍地导入转储，直到脚本在完全导入的转储上完美运行为止。然后将脚本保存到磁盘上的文件中。
3.在生产服务器上运行脚本。
4.将脚本导入SCM。

像其他任何东西一样，在开始弄乱数据之前先备份数据。