『壹』 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上的軟硬融合設計，而這一點，是否需要雲原生資料庫從廣義的定義出發進行學習參考，也是需要進一步討論的。