‘壹’ oracle 数据库、表空间、实例、服务究竟有什么区别联系
1、每个DATABASE--可包含多个INSTANCE--每个INSTANCE可包含多个TABLESPACE和USER等（授予USER读写TABLESPACE的权限）--每个TABLESPACE可包含多个DBF文件--常用的TABLE或VIEW等都存储在TABLESPACE里。
2、要oracle使用
先安装DATABASE，再创建INSTANCE，用sysdba创建TABLESPACE，添加USER指定TABLESPACE，给USER授权，用USER登录，创建table等
3、oracle实例启动后，会有多个进程提供不同的服务。
‘贰’ 服务器是干什么的和数据库有什么区别
服务器是提供计算服务的设备。服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
区别
1、从性质上看：
数据库是可以运行在服务器上的软件。服务器是硬件，服务器安上了数据库应用程序后可以变成数据库服务器。
2、从功能上看：
数据库是可以从数据库是按照数据结构来组织、存储和管理数据的仓库而服务器是用于数据计算和处理的硬件。用来存放客户请求并给出回应的硬件。
(2)数据库即服务形态扩展阅读：
服务器在网络中为其它客户机（如PC机、智能手机、ATM等终端甚至是火车系统等大型设备）提供计算或者应用服务。服务器具有高速的CPU运算能力、长时间的可靠运行、强大的I/O外部数据吞吐能力以及更好的扩展性。
根据服务器所提供的服务，一般来说服务器都具备承担响应服务请求、承担服务、保障服务的能力。服务器作为电子设备，其内部的结构十分的复杂，但与普通的计算机内部结构相差不大，如：cpu、硬盘、内存，系统、系统总线等。
‘叁’ 数据库有哪几种
常用数据库有mysql、oracle、sqlserver、sqlite等。
1、Oracle数据库
Oracle数据库管理系统是由甲骨文（Oracle)公司开发的，在数据库领域一直处于领先地位。目前，Oracle数据库覆盖了大、中、小型计算机等几十种计算机型，成为世界上使用最广泛的关系型数据管理系统（由二维表及其之间的关系组成的一个数据库）之一。
2、SQLServer数据库
SQLServer是由微软公司开发的一种关系型据库管理系统，它已广泛用于电子商务、银行、保险、电力等行业。SQLServer提供了对XML和Internet标准的支持，具有强大的、灵活的、基于Web的应用程序管理功能。
3、DB2数据库
DB2数据库是由IBM公司研制的一种关系型数据库管理系统，主要应用于OS/2、Windows等平台下，具有较好的可伸缩性，可支持从大型计算机到单用户环境。
4、MongoDB数据库
MongoDB是由10gen公司开发的一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似JSON的bjson格式，因此可以存储比较复杂的数据类型。
5、MySQL数据库
MySQL数据库管理系统是由瑞典的MySQLAB公司开发的，但是几经辗转，现在是Oracle产品。它是以“客户／服务器”模式实现的，是一个多用户、多线程的小型数据库服务器。而且MySQL是开源数据的，任何人都可以获得该数据库的源代码并修正MySQL的缺陷。
6、Sybase数据库
美国Sybase公司研制的一种关系型数据库系统，是一种典型的UNIX或WindowsNT平台上客户机／服务器环境下的大型数据库系统。
‘肆’ 数据库管理到底难不难，IT大佬们分享下经验
这个要分情况，作为IT老狗混迹过的企业不在少数，每个企业情况不一样，数据库管理难度也不一样。有的企业用的还是传统的数据库管理系统，非常的繁琐复杂，关键灵活性、稳定性和安全性也不行，即使天天加班都不一定能做好工作。但有的企业，利用先进数据库管理工具的帮助，数据库管理可以实现一键式操作，非常方便快捷。
在这里跟大家推荐个非常好用的数据库管理工具，就是Nutanix最近推出了数据库管理相关的组合产品（NDB）。NDB 面向 PostgreSQL®、MySQL®、Microsoft® SQL 服务器、Oracle® 数据库等数据库引擎，简化了在混合多云环境下的数据库管理，具有非常强大的自动化功能，支持数据库实例的配置、扩展、修补、保护和克隆，还可以帮助客户在本地和公有云上为开发人员提供数据库即服务（ DBaaS ）和易用的自助式数据库体验，是企业进行数据库管理非常有力的工具，大家可以试试∞
‘伍’ 数据库的基础服务怎么进行
数据库基础服务主要包括数据库的开启、关闭、登录等基础性操作，为数据库系统中最常见与最基础的服务操作。下面以在命令行中与GUI客户端工具中为例，对以上服务操作作较详细的说明。开启服务器1.命令行操作数据库命令是数据库系统得以运行的根本保证，各种各样的请求最终都转换成数据库命令，并在数据系统上执行。熟练掌握数据操作命令对数据库开发人员及数据库管理人员至关重要。
在cmd命令行下进入MySQL服务器安装目录（根目录）的bin目录下：先进入MySQL服务的安装盘，再进入其安装路径下的bin目录，操作过程如图5−1所示。或把bin目录的路径配置到操作系统的环境变量的path路径下，则无须在cmd命令行中进入MySQL的bin目录就可直接使用MySQL命令集。
cmd命令进入MySQL服务器bin目录操作
bin目录为MySQL服务器命令的存放目录，在该目录下，找到mysqld.exe或mysqld−nt.exe或mysqld−debug.exe文件。
根据应对文件，选择对应的命令启动：mysqld--consolemysqld−nt--consolemysqld−debug--console每个命令的后面跟的“--console”表示启动信息输出到cmd命令行控制台，最后看到如图服务器启动成功所示的类似信息时，表示启动成功。
2.GUI操作通过GUI操作数据库相对比较简单，对于刚入门的人员是一个不错的选择，下面针对通过GUI如何开启数据库作简单介绍。
服务器启动成功
GUI图形界面启动按如下步骤操作：（（1)右键单击我的电脑→管理→服务和应用程序→服务。
（2）打开系统服务管理界面，找到MySQL服务，并双击打开。
（3）在弹出的“MySQL的属性（本地计算机）”对话框中选择“启动”按钮，如图5−3所示。
GUI启动操作
登录服务器在cmd命令行下进入MySQL服务器安装目录（根目录）的bin目录下，找到mysql.exe文件。
根据应对文件，用如下命令登录：mysql−uroot−proot其中，−u后面跟的是root账号；
−p后面跟的是账号的密码，此处为“root”。
语句的最后一定不能加上分号，否则会把它当成密码的一部分，而导致密码不正确，不能成功登录。最后，如果看到如图登录成功操作所示的信息时表示登录成功。
登录成功操作
关闭服务器在cmd命令行下进入MySQL服务器安装目录（根目录）的bin目录下，找到mysqladmin.exe文件，mysqladmin是MySQL数据库管理的命令，是一个综合性的指令性，能完成众多功能。
根据应对文件，用如下命令关闭：mysqladmin−uroot−prootshutdown其中，−u后面跟的是root账号；
−p后面跟的是账号的密码，此处为“root”；
shutdown为mysqladmin命令的参数。
‘陆’ NewSQL分布式数据库发展策略讨论
作者 石默研
本文对新一代NewSQL分布式数据库发展策略中的普遍困扰进行讨论，包括云原生（Cloud Native）与本地部署(On Premise)、HTAP进展方向、分布式与单机需求等分布式数据库商业与技术发展中难以决策的问题。
1. 困扰
分布式NewSQL数据库近年来蓬勃兴起，其原因显而易见：切中了业务与数据量不断增长的用户对关系型数据库RDBMS需求，这在传统RDBMS到大数据的发展阶段中，有相当一段时间是空白。同时，随着互联网技术的不断发展与普及，用云计算模式满足IT需求似乎已经成为未来 社会 产业互联网发展的明确趋势，也就是说，有一种共识：不久的将来，绝大多数产业的IT服务是从公共的、行业的或者私有的、混合的云计算中心提供的。这一共识又带来了云原生（Cloud Native）概念与技术的兴起，而分布式NewSQL数据库自然也应该是云原生的，这决定了其相当多的产品设计决策应以符合这一趋势为原则。然而，在当今的现实中，满足业务与数据量不断增长的RDBMS需求的用户，与云原生的用户，除了互联网企业外，大多数情况下，并不重合，需要On-Premise部署的用户仍然占有很大比重，这就带来了第一个困扰：云原生（Cloud Native）与本地部署(On Premise)对产品发展要求的矛盾。
另一个困扰，是关于HTAP，即交易与分析混合负载。HTAP是当今非常火的一个概念与技术，在交易库上直接进行分析，而不再是将“数据从交易库搬下来，挪到另一个数据库中去”这样的繁琐过程。可以毫不夸张的说： 历史 上规模性企业IT复杂度的相当一部分，都来自于“搬数据”，这导致了数据采集、实时采集、全增量合并、数据传输、数据加载、数据建模、数据质量、数据标准、企业级元数据管理等繁杂多样的技术环节的产生，导致了企业数据分布、数据流向、数据模型、主数据、基础数据平台、ODS/数据仓库/数据集市、数据治理等复杂的数据架构设计优化领域，导致了由于多系统大规模数据搬迁而带来的如数据交换平台之类的复杂调度工程......。咋眼一看，感觉该企业的数据技术好厉害，相关各领域的技术产品好丰富，技术人员的相关技能也好受欢迎。但如果在交易库就能直接满足分析需求而不影响生产效能的话，这些复杂高级的技术环节不都成了“自己给自己造了一座山，还说自己爬的好辛苦”？然而，现实却是，问题并不这么简单，除了在交易库中进行分析会影响业务效能外，还有很多原因导致这一现象产生：交易库并不需要存储那么长的 历史 数据，而分析往往是需要建立在大量 历史 数据之上的；交易库的模型往往并不适合分析需求，多数情况下需要重要建模，如非常流行且价值不菲的各行业数仓主题模型；用于交易的OLTP数据库与用于分析的OLAP数据库，其技术体系完全不同；以及大型企业已固化的内部业务结构并没有留给交易/分析整合可实施的可行空间......等等。由于， 历史 积累的企业级数据体系相当复杂，HTAP的发明者迄今为止都没有系统表达完全替代数据分析需求、自顶而下重构企业数据体系的架构级策略，而是将产品重点定位在技术优化层面：在交易库上直接完成实时统计分析，满足高并发需求且不影响业务效能；或者是为实时分析统计/查询而建设的数据服务中间平台。然而，即使是暂时没有这种策略性的意向，在面向AP的产品具体研发中，又会发现明确的界限确实不好把握，随着一个个具体功能的不断完善，似乎假以时日，技术上也不是没有完全替代纯OLAP平台的可能性。那么，HTAP究竟如何定位呢？
再者就是规模化的分布式需求，与小规模的单机数据库需求（这里指逻辑上的单机）之间的矛盾：分布式数据库，自然而然是要应对规模化的数据管理需求的，长尾的小规模需求当然不应在产品设计考虑之列，同时，大炮轰苍蝇经常还打不好；然而，分布式NewSQL数据库又应该是云原生的，如果把云原生的业务含义理解为“全自助”，它应该以支持什么样的需求为主呢？现实看来，小规模长尾业务对云原生数据库的需求最起码应该是占据相当大的比重的。显而易见，如果是大规模的数据管理需求，即使是部署在云上，DBPaaS的“全自助”是其核心需求吗？这种规模化的业务，如果是云上的On-Premise又需要做出哪些方面的改变？从互联网与云计算发展的 历史 来看，“云自助”，其最核心的商业动机当然包括给用户侧的运维带来了方便，但更重要的可能是给云服务运营商应对海量长尾客户的安装与运维带来了极大的成本优势。这正如银行的小微及个人消费贷款都要走互联网线上模式，而重客、大客甚至中小企业信贷仍然是以线下为主的策略一样，本质是成本问题，而不是客户方便性问题。于是，矛盾显而易见：分布式是面向规模客户的，起码是中、大型客户，而云原生却有可能、最起码相当一段时间内是要以长尾客户为主要服务对象的。
以上困扰实质上，都涉及到了NewSQL分布式数据库的产品发展策略问题。
2. 讨论
问题是客观而又普遍的，但分析与应对策略往往包含主观因素：人们的一个决定与决策，很多情况下并不由严格推理而来，而是心中已经有一个答案，再来找理由支持它。这里的讨论或许也并不能例外。
首先，来看看Cloud Native与On Premise。云原生本应是数据库即服务，然而目前真正有规模化数据增长需求的NewSQL应用相当多的情况下却是付费On Premise与免费On Premise区别，很多互联网企业的应用也可能只是部署在云基础设施上而已，真正的云原生更多是一些实验性、尝试性的需求。但云原生数据库在公有云、行业云以及大型私有云上已经逐渐在形成一种意识上的共识，其商业前景不可限量。也就是说，未来的数字化转型进程中，产业互联网的数据库部署，会逐渐向云基础设施迁移，长在云上。它可能是公有云，也可能是行业云，也可能是私有云，它们都是被定义为云原生NewSQL数据库的市场范围。当然，肯定还会有相当一部分数据库长在云下，这也不用纠结，将其排除在云原生市场战略目标之外即可，就是说，不需要考虑这部分客户需求对产品规划的影响，因为前一部分的份额已经足够大了。这样看来，以云原生为目标进行产品规划的逻辑没有问题，不过，还是要明确一点：长在云上的数据库是不是一定符合我们对“云原生”的既有理解？这里认为，即使未来，在云上形成了产业互联网数据库市场的主体，需要“全自助”的数据库即服务可能也是以面向长尾客户最为迫切、必不可少并且是核心本质，而对中大型以上的需求，“全自助”的意义相对有限，同时比较而言商业模式的转变或者更关键些。那么，如果是以“长在云上”为市场目标，似乎可以将其定义为“广义的云原生”，同时，只要是“长在云上”，那么“云原生”概念中高弹性、高可用、低成本、快速迭代、存算分离等技术优势也都能方便获得。而对“云原生”策略中“云原生”一词的理解不同，对产品规划决策的影响也应该有所不同：一是目前被认为是On Premise的客户需求，或许也就是未来“云原生”主体市场的需求；二是NewSQL数据库关于云原生服务的产品策划，对用户侧“自助”水平的决策或许可以更灵活实用。高水平自助确实可以减轻客户对IT的依赖程度，但这里认为，云原生与用户自行在云上购买资源进行On-Premise部署相比，最关键的价值在于商业模式的改变，能自助多少，不一定是最重要的，因为成为云服务商后，运营运维的工作只会更多，责任可能会更大，甚至有时连IaaS的运维也需要PaaS服务商兜底。但从一个个客户的本地服务，变成集中化云服务，就已经是本质性的模式转变了。总之，需要就事论事，回到原点，仔细分析后决策，而不是用概念教条的判断，因为概念本身的定义并不见得准确对应实际的业务需求。
再来看看HTAP，对这个问题，正如在其它文章中表达过的一样，本文的观点较为明确。一是随着计算能力与架构的升级，从技术上讲，AP与TP的界限会越来越模糊；另外特别是在云原生的新世界里，数据库的这一特性又犹为重要，因为云原生的重要作用之一就是要让客户尽量摆脱对IT运维的依赖，将越来越多的精力集中到自己的业务发展上来；同时端到端的能力提升对云原生商业模式的贯彻也至关重要（需要仔细分析下目前DBPaaS的技术要求是否完全符合这一原点的、本质性的动力），过去与纯OLAP数据库的优势比较纠结在这里也可以得到正面支持；再者，既然架构上已经走向了AP，就很难做到在产品规划上时刻厘清纯AP与混合负载的需求后，再将前者排除在外。于是，以“混合负载满足部分AP需求”应该是由于投入与阶段性市场策略导致的阶段性产品规划，而长远来讲，以一套技术架构满足大多数需求，应该是云原生NewSQL数据库的追求。
接下来，就是关于规模化分布式与小规模单机需求的矛盾了。现在看来，经过上面的讨论，这一点已经不是什么问题了：因为“长在云上”、从分散服务向集中服务的商业模式转变就是指广义的云原生，而不一定要以小微的、迫切需要全自助的长尾为主流，那么，云原生NewSQL数据库仍然应以规模化分布式为其主体的需求方向，而小规模单机则暂时可以不做为重点来考虑。
最后指出一点，希望也能引发进一步的思考：我们所批判的主机，也声称自己是分布式架构，暂且不论其是否客观，但在现实中主机需要被替代的核心问题并不是有没有分布式，而是：一、扩展不灵活带来成本问题：“我只需要扩展一个节点，你却让我再买一台主机”；二、不自主可控；三、往往是软硬件结合的设计策略，包括内存、网络、存储与IO上的软硬融合设计，而这一点，是否需要云原生数据库从广义的定义出发进行学习参考，也是需要进一步讨论的。