学海无涯苦作舟的博客

Oracle 的 MySQL Operator 是一个在集群内运行的组件，用于自动执行数据库初始化。您不需要 Operator 在 Kubernetes 中使用 MySQL – 您可以使用 StatefulSet自行部署官方容器镜像。但这种方法很麻烦，需要您编写和维护长清单文件才能创建可靠的环境。该操作员提供了一组可用于创建数据库的自定义资源。将对象添加InnoDBCluster到 Kubernetes 集群会提示操作员为您设置 StatefulSet、存储和网络。

你是不是听过PLE (Page Life Expectancy, 页面的预期寿命)，但又不太确定PLE 指的是什么意思？通常当资料库遇到效能问题的时候，PLE 的数值往往可以提供一些调校的方向。PLE 指的是资料页面停留在记忆体缓存区（buffer pool) 的秒数时间。如果资料页面可以停留在缓存区久一点，资料库就可以不需要透过读取硬碟而可以直接从缓存区直接取得资料，相对的，资料库效能就会高一些。所以PLE 数值越高，对资料库效能来说则是越好。PLE 数值可以透过以下的查询方法取得。SELECT ob

没有搞懂它前,似懂非懂的,东拼西凑,也能写出程式.但搞懂它,更知道自己在写什么.key word : sql joinA与B的配对游戏inner join配对到的A和B都站出来left join A都站出来,有配对到的带着B出来.接着我们也可以再把有配对到的给踢掉.right join B都站出来,有配对到的带着A出来.接着我们也可以再把有配对到的给踢掉.FULL OUTER JOIN A,B都站出来.接着我们可以把有配对到的给踢掉.以上是概念,以下是语法实作DROP TABLE #TMP

几个月前，Business Intelligence 部门跑来跟DBA 讨论，希望可以设定一个复制数据库的排程，每天将约20 TB 的数据库复制到另一个SQL Server 供数据科学家们(Data Scientists) 使用。没错！是20 TB, 而且是每天的排程(on a daily basis)。设定backup 与restore 的复制排程听起来相当容易，但问题是如果使用SQL Server 内建的复原方法， 20 TB数据库的复制程序推算大概要花26个小时才能完成，但每个人每一天都只有24小时

很多人都以为只要有SQL SA (sysadmin) 权限，就万无一失.真的是这样吗？问题:在一个资料库里面，除了dbo schema外，还有另外一个schema ABC.有一个login (Jason) 的default schema 设定为ABC.但是在run 以下的query, SQL 找不到在schema ABC 里的table.Select * from table;但是只要加了schema 在table前面，就可以了。如下。Select * from ABC. table;

下面这张图说明了SQL Server AlwaysOn 可用性群组(AOAG) 在高可用性(HA – High Availability) 与灾害复原(DR – Disaster Recovery) 的使用。通常而言，HA nodes 会设在同一个data center, 由于在同一个subnet 里, 网络的延迟latency 比较低， 所以通常采用同步的(synchronous) 资料复制设定。至于DR node, 设定在不同subnet 的data center 里，网络延迟会较高，所以资料复制一般采

前一阵子，发现一台SQL Server 的compute 性能好像不如预期的好。仔细检查一下，发现这一个SQL Server VM 有8 个cores, 但是SQL Server 好像都只用了一半CPU 的compute power. 用select @@version 指令查看安装的SQL Server 版本，结果是Standard Edition。到此，几乎可以断定问题的所在了。进一步检查VM 的CPU 设定为8 sockets with single core (8 x 1 = 8 cores).

在SQL Server, 死结的发生是因为有两个或多个工作（processes) 正在互相等待彼此所保留锁着的资源，而造成工作永久封锁彼此的情况。当deadlock 发生时， SQL Server 会自行选择其中一个工作作为牺牲者，以错误来结束其交易。如下。一般来讲， DBA 会开启设定trace flag (1222) 来搜集deadlock 的信息，以便分析deadlock 的发生。另外一个方法就是使用扩充事件(Extended Events) 的system_health 工作阶段(Session

今天早上Data warehouse 部门的人告诉我平常的Data loading时间还算正常，但是昨天晚上的loading 时间比一般平常的时间长很多，是不是数据库有什么问题？我仔细检查了一下数据库，发现昨天的数据档案MDF file 已经满了，数据库自动加了10GB 来增大这一个数据档案。我又跟着进一步检查IFI 的设定，发现这个设定没有被启用。几乎可以肯定这个就是问题的所在.什么是IFI 呢？IFI 就是Instant file initialization. 当数据库要取得硬盘空间来扩增数据档案

请点击输入图片描述（最多18字）大多数SQL Server 的服务器验证都是设为mixed mode, 就是SQL Server 及Windows 验证模式。较具规模的IT, 由于安全性的考量，都是尽可能避免用SQL Server 认证，而采用Windows 认证。一般来讲，都是以AD groups (Active Directory) 来管理数据库安全。举个例子来说，数据库部门有三名DBA，在这种情况下，可以设定一个AD 的SA (sysadmin) 群组， 然后将三名DBA 的AD 帐号加入这个AD

没有SA 权限的使用者，要如何管理SQL Agent Jobs?在MSDB 系统数据库里，有三个database roles 可以管理SQL Agent John Jobs. 可以透过以下的语法找到这些roles.其中…SQLAgentUserRole 权限可以管理自己拥有的jobs.SQLAgentReadRole 权限可以有包含上述SQLAgentUserRole 的权限以外，还可以有审视jobs 的设定与执行记录。SQLAgentOperatorRole 权限可以有包含上述SQLAgent

有听过资料库的collation （校对）设定吗？讲到collation，最常提到的就是英文大小写case sensitive 跟case insensitive. 安装SQL Server 资料库，instance level 的内定collation 设定是SQL_Latin1_General_CP1_CI_AS，就是case insensitive.常见的问题是可以在同一个SQL instance 下建立不同collation 的databases 吗？答案是可以的。可以自己试看看喔。..

最简单的方法就是右键点击数据库，然后选择属性。在左边的选取页面点击选项。就可以在右手边看到数据库复原模式。如下图。但是如果你有一二十个, 或者更多的数据库，一个一个查询数据库复原模式太辛苦了。简单的方法是在SSMS 物件总管选取数据库，然后按F7 键，就会列出所有数据库复原模式的设定。如下图。还有一个蛮酷的方法是用SQL script.SELECT name DB, recovery_model_desc RecoveryModelFROM sys.databases;GO如下图。

这里所讲的设定是指安装SQL数据库时的设定。如果你只需要管理三到五个数据库，设定标准化可能不是那么重要，但是如果你要管理数据中心内500个到1000个数据库，标准化可以让DBA的日子好过一点。举个例子来说，在安装SQL server 数据库的时候，使用如下的设定标准：SQL binary: D:\MDFs: G:\MSSQL\dataLDFs: L:\MSSQL\logsTempdb: T:\MSSQL\当你接到on-call 的电话，告诉你G drive 没有空间了，你马上就知道要叫Storag

如果你正在思考未来的职涯规划，准备投入或转换DBA 跑道，可以参考以下几个方向来作准备。1，如果你本身是Developer 程式开发或是数据库开发人员，可以开使接触学习infrastructure 的基本知识与专业用语。相对的，如果你是System Admin 系统管理人员，就必须开始学习了解Developer 的领域与基本的专业用语。通常在跨部门的会议里，支援硬件的人员很难跟支持软件的人员沟通，因为彼此沟通的出发点不同，用的专业用语也不同，有时候又不好意思说自己听不懂不熟悉的专业用语，所以常常会有鸡同鸭

在处理数据库还原的时候，常常会出现(the database is in use) 错误信息。顾名思义，就是因为还有人或者是应用程式还正在连结使用这个数据库， 所以SQL Server 拒绝让任何人还原这个数据库。解决办法很简单，就是用sp_who2 找出连线的SPID ( Server Process ID), 然后用kill 指令杀掉这个SPID. 就可以继续进行数据库还原的动作了。如果只有一两个SPIDs 要kill, 可以慢慢用kill 指令来处理，但若有几十个或几百个SPIDs 要kill