SQL数据库并发处理(如何处理数据库并发问题)

并发（concurrent）和并行（parallel）这两个概念，在数据库系统的资料中经常出现，然而有关它们的定义和区别却没有明确的说法。这里，我们根据这两个概念在资料中的使用，对它们的不同做一个说明。

并发是指多个任务的同时执行，任务与任务之间没有联系。由于数据库系统要同时为许多用户提供服务，每个用户都可以发出自己的访问请求，一个请求就是一个任务。在一个时间点，数据库系统可能要同时处理多个任务。因此，数据库系统一定要具备并发处理能力。

并行是指将一个任务划分为多个子任务，这些子任务同时执行。在所有子任务处理完成后，将它们的结果进行合并，就得到该任务的最终处理结果。在数据库系统中，如果要执行一个大的数据查询，为了提高速度、降低响应时间，用户可以通过系统配置或者在命令中，要求对该大数据量查询进行并行处理，将该查询划分成多个子查询。这些子查询同时执行，最后系统将所有子查询的处理结果进行合并，作为该查询处理的最终结果。现有的大型数据库系统都支持并行处理。

需要说明的是，并发和并行与数据库系统采用多进程还是多线程体系结构无关。对采用多进程结构的数据库系统，所有的任务、子任务通过进程来处理；而对采用多线程结构的数据库系统，这些工作是由线程来完成。

数据库系统的并发控制，涉及到任务的调度、数据的一致性及可靠性等，而数据库系统的并行处理，主要涉及任务的处理速度、系统性能等方面。

1、DBWR进程：该进程执行将缓冲区写入数据文件，是负责缓冲存储区管理的一个Oracle后台进程。当缓冲区中的一缓冲区被修改，它被标志为“弄脏”，DBWR的主要任务是将“弄脏”的缓冲区写入磁盘，使缓冲区保持“干净”。由于缓冲存储区的缓冲区填入数据库或被用户进程弄脏，未用的缓冲区的数目减少。当未用的缓冲区下降到很少，以致用户进程要从磁盘读入块到内存存储区时无法找到未用的缓冲区时，DBWR将管理缓冲存储区，使用户进程总可得到未用的缓冲区。Oracle采用LRU（LEAST RECENTLY USED）算法（最近最少使用算法）保持内存中的数据块是最近使用的，使I/O最小。在下列情况预示DBWR 要将弄脏的缓冲区写入磁盘：当一个服务器进程将一缓冲区移入“弄脏”表，该弄脏表达到临界长度时，该服务进程将通知DBWR进行写。该临界长度是为参数DB-BLOCK-WRITE-BATCH的值的一半。当一个服务器进程在LRU表中查找DB-BLOCK-MAX-SCAN-CNT缓冲区时，没有查到未用的缓冲区，它停止查找并通知DBWR进行写。出现超时（每次3秒），DBWR 将通知本身。当出现检查点时，LGWR将通知DBWR在前两种情况下，DBWR将弄脏表中的块写入磁盘，每次可写的块数由初始化参数DB-BLOCK- WRITE-BATCH所指定。如果弄脏表中没有该参数指定块数的缓冲区，DBWR从LUR表中查找另外一个弄脏缓冲区。如果DBWR在三秒内未活动，则出现超时。在这种情况下DBWR对LRU表查找指定数目的缓冲区，将所找到任何弄脏缓冲区写入磁盘。每当出现超时，DBWR查找一个新的缓冲区组。每次由DBWR查找的缓冲区的数目是为寝化参数DB-BLOCK- WRITE-BATCH的值的二倍。如果数据库空运转，DBWR最终将全部缓冲区存储区写入磁盘。在出现检查点时，LGWR指定一修改缓冲区表必须写入到磁盘。DBWR将指定的缓冲区写入磁盘。在有些平台上，一个实例可有多个DBWR在这样的实例中，一些块可写入一磁盘，另一些块可写入其它磁盘。参数DB-WRITERS控制DBWR进程个数。 2、LGWR进程：该进程将日志缓冲区写入磁盘上的一个日志文件，它是负责管理日志缓冲区的一个Oracle后台进程。LGWR进程将自上次写入磁盘以来的全部日志项输出，LGWR输出：◆当用户进程提交一事务时写入一个提交记录。

◆每三秒将日志缓冲区输出。

◆当日志缓冲区的1/3已满时将日志缓冲区输出。

◆当DBWR将修改缓冲区写入磁盘时则将日志缓冲区输出。LGWR进程同步地写入到活动的镜象在线日志文件组。如果组中一个文件被删除或不可用，LGWR可继续地写入该组的其它文件。日志缓冲区是一个循环缓冲区。当LGWR将日志缓冲区的日志项写入日志文件后，服务器进程可将新的日志项写入到该日志缓冲区。LGWR 通常写得很快，可确保日志缓冲区总有空间可写入新的日志项。注意：有时候当需要更多的日志缓冲区时，LWGR在一个事务提交前就将日志项写出，而这些日志项仅当在以后事务提交后才永久化。ORACLE使用快速提交机制，当用户发出COMMIT语句时，一个COMMIT记录立即放入日志缓冲区，但相应的数据缓冲区改变是被延迟，直到在更有效时才将它们写入数据文件。当一事务提交时，被赋给一个系统修改号（SCN），它同事务日志项一起记录在日志中。由于SCN记录在日志中，以致在并行服务器选项配置情况下，恢复 *** 作可以同步。 3、CKPT进程：该进程在检查点出现时，对全部数据文件的标题进行修改，指示该检查点。在通常的情况下，该任务由LGWR执行。然而，如果检查点明显地降低系统性能时，可使CKPT进程运行，将原来由LGWR进程执行的检查点的工作分离出来，由CKPT进程实现。对于许多应用情况，CKPT进程是不必要的。只有当数据库有许多数据文件，LGWR在检查点时明显地降低性能才使CKPT运行。 CKPT进程不将块写入磁盘，该工作是由DBWR完成的。初始化参数CHECKPOINT-PROCESS控制CKPT进程的使能或使不能。缺省时为FALSE，即为使不能。 由于Oracle中LGWR和DBWR工作的不一致，Oracle引入了检查点的概念，用于同步数据库，保证数据库的一致性。在Oracle里面，检查点分为两种：完全检查点和增量检查点。下面我们分别介绍这两种检查点的作用：1、完全检查点 在Oracle8i之前，数据库的发生的检查点都是完全检查点，完全检查点会将数据缓冲区里面所有的脏数据块写入相应的数据文件中，并且同步数据文件头和控制文件，保证数据库的一致。完全检查点在8i之后只有在下列两种情况下才会发生：（1)DBA手工执行alter system checkpoint的命令；（2)数据库正常shutdown（immediate,transcational,normal）。由于完全检查点会将所有的脏数据库块写入，巨大的IO往往会影响到数据库的性能。因此Oracle从8i开始引入了增量检查点的概念。

2、 增量检查点Oracle从8i开始引入了检查点队列这么一种概念，用于记录数据库里面当前所有的脏数据块的信息，DBWR根据这个队列而将脏数据块写入到数据文件中。检查点队列按时间先后记录着数据库里面脏数据块的信息，里面的条目包含RBA（Redo Block Address，重做日志里面用于标识检查点期间数据块在重做日志里面第一次发生更改的编号）和数据块的数据文件号和块号。在检查点期间不论数据块更改几次，它在检查点队列里面的位置始终保持不变，检查点队列也只会记录它最早的RBA，从而保证最早更改的数据块能够尽快写入。当DBWR将检查点队列里面的脏数据块写入到数据文件后，检查点的位置也要相应地往后移，CKPT每三秒会在控制文件中记录检查点的位置，以表示Instance Recovery时开始恢复的日志条目，这个概念称为检查点的“心跳”（heartbeat）。检查点位置发生变更后，Oracle里面通过4个参数用于控制检查点位置和最后的重做日志条目之间的距离。在这里面需要指出的是，多数人会将这4个参数看作控制增量检查点发生的时间。事实上这是错误的，这4个参数是用于控制检查点队列里面的条目数量，而不是控制检查点的发生。

NET平台很棒。真的很棒。直到它不再那么棒。我为什么不再用NET？简单来说，它限制了我们选择的能力(对我来说很重要)，转移了我们的注意力，使得我们向内认知它的安全性，替代了帮助我们认知外面广阔世界的所有可能性。[系好安全带：这个文章的长度几乎成了一本书…]优点首先让我开始说说NET做得对的许多事吧，尽管这其中的大多数并不来自NET本身，但却是由NET社区而来。C#C#令人惊叹。我认为它是一个令人惊叹的编程语言。从强大的C语言背景而来，我彻底地喜欢其语法，流和这门语言的所带来的感觉。当然有我可能改变的事，但总体来说它是一门扎实的语言。并且基于开发人员使用的编程语言如此巨额的百分比和Windows *** 作系统的优越性，它是一门众所周知的语言。ReSharper我也很喜欢Resharper。在JetBrains工作的开发者们都是奇迹般的人。如果没有ReSharper和一些相关的工具，我可能并不会如此喜欢C#。BDDandMSpec我也很喜欢简称为机器规格(mspec)的BDD风格的框架。它是一个令人惊叹的测试框架，真正支持在测试中使用正确的语言测试本身。在使用mspec之前，我的测试真是一团糟并且很碍我的事。另外，当我们创建GoConvey—基于Golang的BDD测试框架的时候，Mspec对于我的组织来说是一个巨大的灵感和激励。多语言运行时我认为多语言的CLR(公共语言运行时)的观念真得使得JVM的世界思考着。我不知道任何非Java的JVM语言在CLR之前，但随着“公共语言运行时”的到来，我的理解是这使得使用JVM的人们向前进并且最终创造了如Scala和Clojure这样伟大的JVM编程语言。如果我错了请纠正我。再者，CLR使得Sun公司的人们坐下来并关注它，因为Java有一点陈旧并且随着Java8的到来，仅仅现在才在多个方面追赶着。竞争是一件非常好的事。NuGet另一个显著的例子是NuGet。这个包在Windows中作为一个整体特别是在Windows的开发中，它的管理轶事是糟透的。NuGet解决了很多问题，他们也通过从Python和Ruby借用了很多东西去做了很多正确的事。有改进的余地吗？当然。但比起其他一些选择在这儿或那儿的包升级来说，我还没有感到使用NuGet有这许多痛楚。Mono对于Mono的开发者们，我不能不说太棒了。他们所创造的太惊奇了。没有任何官方支持和不顾潜在的悬在他们头上的法律问题，他们向前推进并创造了一个居然能替代官方运行时的实现。我已经有一些运行在产品中应用程序，在Mono下运行了几乎一年而没有任何问题。它的产品准备好了吗？这可能取决于你的应用程序(见下文“Mono”)。CQRS和事件溯源可以认为，关于NET最好事之一是，它是CQRS的诞生地并有相关的技术：事件溯源。就算这样，CQRS+ES本身并没有什么很新的东西。正如GregYoung将会告诉你的，这是由一堆40年历史原料为我们重新打包并更名的。对于大型代码库我有些非常严重的问题，当我5年前使用CQRS+ES的时候，它完全释放了我的域。CQRS+ES现在是命名模式的并且其成长是显而易见的。这可能是因为NET已经能够和其他的开发平台交互共享的原因。除了这个之外，大多数的创新是从外部来的。缺点优点先放在一边，让我们看看什么出错了和我为什么不再用NET框架。关于我最近开发平台的迁移，最能激励我的事是我可以利用许多最好的部分而丢下不好的部分(如下文所说)。Windows正如前文所述，当面对基于网络的服务器软件时，Windows并不是一个好的选手。在我看来，Windows的另一个真正的大问题是传统的Windows开发者是通常仅仅擅长于Windows，当他们离开安乐窝之后就会很快迷失，这对于Linux开发者来说却不是问题。计算远不止是Windows。开发者仅仅能 *** 作单一的 *** 作系统的一个问题是它不可避免得导致Windows的激增。换句话说，Windows生了Windows。没法打破这个循环。另一方面，NIX的开发者通常熟悉多 *** 作系统(Linux，Unix，OSX，Windows等等)，一个 *** 作系统的内部工作原理，不同的分布(基于Debian和基于Fedora)，窗口管理器，桌面管理器，文件系统，包管理，编译，重新编译，重新打包，命令行“fu”等等。我的一个心病是文件系统。NTFS并不是系统唯一的文件系统，对于任何给予的任务它几乎都不是最好的选择。ZFS，BTRFS，ReiserFs，ext等等，有一些很酷的特性。我也很喜欢为了各种高速/透明的磁盘 *** 作，能从BASH创建回路设备或者创建RAM设备。这在Windows中不会发生—如果没有第三方软件的话。在AWS云服务中，启动一个Windows机器要花掉足足10多分钟。我大约15-20秒就能启动一个简单的Linux机器。当涉及到云计算规模，它能够迅速扩展是很重要的，因为当扩展很重要时，10-15分钟就像是永恒的。VisualStudio在我这另一根刺，当属VisualStudio。我需要一个大大超出预期的IDE去做任何开发，这个想法困扰着我。它只是如Windows一样庞大的资源猪。我有一个内核i73770K35GHZ的台式机，以16GB的内存和最大4512GB的固态硬盘去编译。它差不多刷爆了Windows体验指数，但Windows+VS仍然很慢。(是的，ReSharper使得它更慢了，但是ReSharper对这来说是值得的。)现在我在MacBookPro上开发，它比起我的强大的台式机来说只有更少的CPU马力，但运行明显更快，在一个短小的学习曲线之后，UX（用户体验）变得无限美好了。事实上，我甚至不再用鼠标了—我的双手一直在键盘或触控板上，我可以用手势 *** 作我的电脑并让它回应—不像在Windows。关于VS很酷的一个事是调试器。它的查看和使用，令人难以置信得方便。每隔一段时间会在监视窗口报告错误的值，导致花费时间去调试。同时，这也是很大的负面，因为CLR默认的，多线程的世界使得我一开始就需要一个调试器。没有调试器是一个解脱的体验，因为它迫使你以另一种方式编程。VS同样也有创建“csproj”和“sln”文件的坏毛病。我恨这些。当然，C#必须知道编译什么和何时编译。我理解这点。在Golang中，引用在代码中使用了很重要的语句。如果它不是NET中用到的工程文件，我可能使用简单的文本编辑器编码C#，并且对这门语言更流畅。使用gitrebase *** 作时，这些文件也有导致合并冲突。别让我开始说换行符的差异。我不能相信直到今天我们还在处理这样的事。如果VS解决方案文件以Linux行结束符结束，通过双击它并不能载入该解决方案，因为VS解决方案文件分析器读不出它来。源代码管理幸运的是，我早就跳出了微软阵营的源代码管理(版本控制系统VSS)。我早在2000年初，在VSS无数次丢失了我的提交之后，就使用了Subversion(译者注：Subversion是开源的版本控制系统)。之后git(译者注：git是开源的版本控制系统，内容管理系统等)出现了，我又迷上了它。不幸的是，没有Windows的接口—对我来说是典型的遭遇。最终有人创建了一个接口，我就用了那个并且没有回头。Git是一把非常锋利的刀，但当你正确运用它的时候，它是一个强大而高效的工具。我曾经在一个小工程中用过TFS(译者注：TeamFoundationServer，工作流协作引擎)，它是一个怪物—和所有来自Redmond(译者注：美国微软总部)的产品一样。它感染了我的项目文件并且污染了我的源代码目录。真可恶。不，还是谢谢你。给了我任意一天用命令行git…或者可能是SourceTree，如果你需要从GUI得到一点关爱。Mono是的，这是第二次提及Mono。正如Mono本身如此惊艳一样。在NET的世界，它仍然二等公民。无论什么时候我尝试在Mono上运行任何重要的东西，我通常都在和漏洞作斗争。幸运的是，对下载代码，查找问题，发送请求和在Linux上编译代码我没有感到不舒服。但是这件事我都记不清做了多少遍了。是的，CLR是个巨大的怪物，并且对一个非官方的应用在不同的 *** 作系统都有相同的行为，简直是个类似于分开红海的奇迹。但事实是，我不得不花费如此多的时间来填补漏洞以使我的代码能够正确运行，实在是很难为其辩护。Mono的特定区域也慢。也许它不是在慢在过载，但对我来说Web服务器是关键所在。并且它非常慢，最后，慢到了最底下—即使是微不足道的东西。我想好消息是它只能从这儿得到更好的。我也应该提及Mono的开发者可能忘了Linux，比起我可能知道的还多，所以我不能太挑剔。IIS也许IIS在尝试着为太多的应用程序做太多的事情。它从作为一个web服务器变为像J2EE应用程序容器一样的应用程序宿主。它也站在慢速这一边。我猜如果我需要更高的性能，我应该编写我自己的web服务器，但我真的很想只关注我应用程序的代码。可能利用Windows事件服务器将是好的，但nginx(译者注：一个高性能的>

以上就是关于SQL数据库并发处理(如何处理数据库并发问题)全部的内容，包括:SQL数据库并发处理(如何处理数据库并发问题)、简要说明多进程oracle实例进程中各后台进程的作用、为什么 MySQL 使用多线程，而 Oracle 和 PostgreSQL 使用多进程等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！