① nds slot-1 slot-2
好運氣。。。
去電玩店買張SLOT1燒錄卡，100元左右的推薦R4和TT，但玩游戲基本都要補資料庫，很蛋疼。。。
最好是選DStwo,什麼煩惱都沒有，游戲出了絕對能玩，而且內置GBA模擬器，所以就不用買SLOT2燒錄卡了。就是貴點。。。
中檔的DSOne，和AK2還可以，基本不用擔心游戲更新和反燒錄的問題，而且價格不貴。
還有M3DSR等等，沒研究過，不亂說。。。
以上
② 怎麼計算sql2000資料庫一條記錄佔用的空間
這個得去看看SQL存儲結構了 網路知道這9999個字元說不完的
SQL2000 數據分為數據文件與日誌文件
數據文件 按盤區來分
一個盤區64K
一個盤區有8個頁
一個頁有8K
頁又大致可分
數據頁,索引頁,文本圖像對象頁，映射頁，可用空間頁
數據頁包含
數據頭部位元組 96位元組
數據區（含多個槽（solt））,一條數據就是一個槽slot
行偏移數組
要具體算數據空間以及槽中存放的是什麼數據,得換算
需用用到
DBCC Page
EXEC sp_spaceused
自己COOLGE一下把 Sqlserver存儲結構
③ 資料庫系統概念第六版中第二章的section關系與time_slot關系中每個屬性怎莫理解
就是每節課的時間節點 說白了 就是第幾節課 A是第一節 B是第二節 仔細看那個time_slot的定義 time_slot_id後面還有start_hr start_min就是開始時間 end_hr end_min就是結束時間
④ 如何查看資料庫的密碼
如何查看mysql資料庫的登錄名和密碼：
通過Windows的服務管理器查看。首先安裝Maki5。服務端 「開始」－「運行」，輸入「services.msc」，回車。彈出Windows的服務管理器，然後就可以看見服務名為「mysql」的服務項了，其右邊標明「已啟動」。
注意：裝好MYSQL後最好重新啟動系統。
1.將服務端Zebra目錄復制到MYSQL的DATA目錄下
2.找到MYSQL目錄里的MY.INI文件，修改my.ini配置文件的[mysqld]下增加lower_case_table_names=2，確定表名和庫名是大小寫敏感的，改完後重新啟動mysql。這段添加完成後，需要將MYSQL服務關閉重啟方可生效(不要在任務管理器里關閉程序)，可以重起一下機器。
3.將「Maki5」這個目錄復制到C盤以外的盤，最好不要用中文名，比如放在E盤的Maki5目錄下
4.打開ConfigTool.exe這個程序就是伺服器啟動的主程序，
5.設置這里讀取MYSQL資料庫的ROOT名和密碼，這里的用戶名一般就是ROOT，密碼改成自己剛才安裝MYSQL時所輸入的密碼，注意，這里有好幾處需要改的，圖的上面所畫圈的項目里的密碼都要改成自己的，否則連接不上，全部修改完後別忘了保存。
6.看一下啟動設置里的程序目錄是否正確，所有運行的程序都要指定在自己所在的目錄，比如E:\Maki5\目錄
7.現在點擊啟動運行看看效果，就可以查看了。
如何修改MySql資料庫的用戶名和密碼：
首先進入命令行下：
以root用戶登錄，命令：mysql -uroot -p 回車 輸入密碼；
mysql>use mysql；
mysql>UPDATE user SET password=PASSWORD('輸入新密碼') WHERE user='root';
mysql>FLUSH PRIVILEGES;
已經完成。
⑤ Oracle資料庫鎖的常用類型有哪些
Oracle資料庫的鎖類型
根據保護的對象不同，Oracle資料庫鎖可以分為以下幾大類：DML鎖（data locks，數據鎖），用於保護數據的完整性；DDL鎖（dictionary locks，字典鎖），用於保護資料庫對象的結構，如表、索引等的結構定義；內部鎖和閂（internal locks and latches），保護資料庫的內部結構。
DML鎖的目的在於保證並發情況下的數據完整性，本文主要討論DML鎖。在Oracle資料庫中，DML鎖主要包括TM鎖和TX鎖，其中TM鎖稱為表級鎖，TX鎖稱為事務鎖或行級鎖。
當Oracle執行DML語句時，系統自動在所要操作的表上申請TM類型的鎖。當TM鎖獲得後，系統再自動申請TX類型的鎖，並將實際鎖定的數據行的鎖標志位進行置位。這樣在事務加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標志，而只需檢查TM鎖模式的相容性即可，大大提高了系統的效率。TM鎖包括了SS、SX、S、X等多種模式，在資料庫中用0－6來表示。不同的SQL操作產生不同類型的TM鎖。如表1所示。
在數據行上只有X鎖（排他鎖）。在 Oracle資料庫中，當一個事務首次發起一個DML語句時就獲得一個TX鎖，該鎖保持到事務被提交或回滾。當兩個或多個會話在表的同一條記錄上執行DML語句時，第一個會話在該條記錄上加鎖，其他的會話處於等待狀態。當第一個會話提交後，TX鎖被釋放，其他會話才可以加鎖。
當Oracle資料庫發生TX鎖等待時，如果不及時處理常常會引起Oracle資料庫掛起，或導致死鎖的發生，產生ORA-60的錯誤。這些現象都會對實際應用產生極大的危害，如長時間未響應，大量事務失敗等。
TX鎖等待的分析
在介紹了有關地Oracle資料庫鎖的種類後，下面討論如何有效地監控和解決鎖等待現象，及在產生死鎖時如何定位死鎖的原因。
監控鎖的相關視圖 數據字典是Oracle資料庫的重要組成部分，用戶可以通過查詢數據字典視圖來獲得資料庫的信息。和鎖相關的數據字典視圖如表2所示。
TX鎖等待的監控和解決在日常工作中，如果發現在執行某條SQL時資料庫長時間沒有響應，很可能是產生了TX鎖等待的現象。為解決這個問題，首先應該找出持鎖的事務，然後再進行相關的處理，如提交事務或強行中斷事務。
死鎖的監控和解決在資料庫中，當兩個或多個會話請求同一個資源時會產生死鎖的現象。死鎖的常見類型是行級鎖死鎖和頁級鎖死鎖，Oracle資料庫中一般使用行級鎖。下面主要討論行級鎖的死鎖現象。
當Oracle檢測到死鎖產生時，中斷並回滾死鎖相關語句的執行，報ORA-00060的錯誤並記錄在資料庫的日誌文件alertSID.log中。同時在user_mp_dest下產生了一個跟蹤文件，詳細描述死鎖的相關信息。
在日常工作中，如果發現在日誌文件中記錄了ora-00060的錯誤信息，則表明產生了死鎖。這時需要找到對應的跟蹤文件，根據跟蹤文件的信息定位產生的原因。
如果查詢結果表明，死鎖是由於bitmap索引引起的，將IND_T_PRODUCT_HIS_STATE索引改為normal索引後，即可解決死鎖的問題。
表1 Oracle的TM鎖類型
鎖模式 鎖描述 解釋 SQL操作
0 none
1 NULL 空 Select
2 SS(Row-S) 行級共享鎖，其他對象只能查詢這些數據行 Select for update、Lock for update、Lock row share
3 SX(Row-X) 行級排它鎖，在提交前不允許做DML操作 Insert、Update、Delete、Lock row share
4 S(Share) 共享鎖 Create index、Lock share
5 SSX(S/Row-X) 共享行級排它鎖 Lock share row exclusive
6 X(Exclusive) 排它鎖 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive
表2 數據字典視圖說明
視圖名 描述 主要欄位說明
v$session 查詢會話的信息和鎖的信息。 sid,serial#：表示會話信息。
program：表示會話的應用程序信息。
row_wait_obj#：表示等待的對象。
和dba_objects中的object_id相對應。
v$session_wait 查詢等待的會話信息。 sid：表示持有鎖的會話信息。
Seconds_in_wait：表示等待持續的時間信息
Event：表示會話等待的事件。
v$lock 列出系統中的所有的鎖。 Sid：表示持有鎖的會話信息。
Type：表示鎖的類型。值包括TM和TX等。
ID1：表示鎖的對象標識。
lmode,request：表示會話等待的鎖模式的信
息。用數字0－6表示，和表1相對應。
dba_locks 對v$lock的格式化視圖。 Session_id：和v$lock中的Sid對應。
Lock_type：和v$lock中的type對應。
Lock_ID1： 和v$lock中的ID1對應。
Mode_held,mode_requested：和v$lock中
的lmode,request相對應。
v$locked_object 只包含DML的鎖信息，包括回滾段和會話信息。 Xisn,xidslot,xidsqn：表示回滾段信息。和
v$transaction相關聯。
Object_id：表示被鎖對象標識。
Session_id：表示持有鎖的會話信息。
Locked_mode：表示會話等待的鎖模式的信
息，和v$lock中的lmode一致。
col owner for a12
col object_name for a16
select b.owner,b.object_name,l.session_id,l.locked_mode
from v$locked_object l, dba_objects b
where b.object_id=l.object_id;
select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;
如果有長期出現的一列，可能是沒有釋放的鎖。我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖：
alter system kill session 'sid,serial# ';
如果出現了鎖的問題, 某個DML操作可能等待很久沒有反應。
當你採用的是直接連接資料庫的方式，也不要用OS系統命令 $kill process_num 或者 $kill -9 process_num來終止用戶連接，因為一個用戶進程可能產生一個以上的鎖, 殺OS進程並不能徹底清除鎖的問題
Oracle鎖表(死鎖) 2011-05-03 17:46:41| 分類： Java技術 | 標簽： |字型大小大中小 訂閱 .
資料庫與操作系統一樣，是一個多用戶使用的共享資源。 當多個用戶並發地存取數據時，在資料庫中就會發生多個事務同時存取同一數據地情況。 若對並發操作不加控制就可能會讀取和存儲不正確地數據，破壞資料庫地一致性。 加鎖時實現資料庫並發控制地一個非常重要地技術。 在實際應用中經常會遇到地與鎖相關地異常情況，當兩個事務需要一組有沖突的鎖，而不能將事務繼續下去的話，就會出現死鎖，嚴重影響應用的正常執行。
在資料庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共享鎖（即S鎖）。當數據對象被加上排它鎖時，其他的事務不能不能對它讀取和修改。加了共享鎖的數據對象可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖類型來對資料庫的事務進行並發控制。
死鎖的第一種情況：
一個用戶A訪問表A（鎖住了表A），然後又訪問表B； 另一個用戶B訪問表B（鎖住了表B），然後企圖訪問表A；這時用戶A由於用戶B已經鎖住表B，它必須等待用戶B釋放表B才能繼續，同樣用戶B要等用戶A釋放表A才能繼續，這就死鎖產生了。
解決方法：
這種死鎖比較常見，是由於程序的BUG產生的，除了調整程序的邏輯沒有其它的辦法。仔細分析程序的邏輯，對於資料庫的多表操作時，盡量按照同樣的順序進行處理，盡量避免同時鎖定兩個資源，如操作A和B兩張表時，總是按先A後B的順序處理，必須同時鎖定兩個資源時，要保證在任何時刻都應該按照相同的順序來鎖定資源。
死鎖的第二種情況
用戶A查詢一條記錄，然後修改該條記錄；這時用戶B修改該條記錄，這時用戶A的事務里鎖的性質由查詢的共享鎖企圖上升到獨占鎖，而用戶B里的獨占鎖由於A有共享鎖存在必須等A釋放掉共享鎖，而A由於B的獨占鎖而無法上升到獨占鎖也就不可能釋放共享鎖，於是出現了死鎖。這種死鎖比較隱蔽，但在稍大點的項目種經常發生，如在某項目中，頁面上的按鈕點擊後，沒有使按鈕立刻失效，使得用戶會多次快速點擊同一按鈕，這樣同一段代碼對資料庫同一條記錄進行多次操作，很容易就出現這種死鎖的情況。
解決方法：
1、對於按鈕等控制項，點擊後使其立刻失效，不讓用戶重復點擊，避免對同時對同一條記錄操作。
2、使用樂觀鎖進行控制。樂觀鎖大多是基於數據版本（version）記錄機制實現。即為數據增加一個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫增加一個「version」欄位來實現。讀取處數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交的數據的版本數據與資料庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於資料庫表當前版本號，則予以更新，否則認為是過期數據。樂觀鎖機制避免了長事務中的資料庫加鎖開銷（用戶A和用戶B操作過程中，都沒有對資料庫加鎖），大大提升了大並發量下的系統整體性表現。 Hibernate在其數據訪問引擎中內置了樂觀鎖實現。需要注意的是，由於樂觀鎖機制是我們的系統中實現，來自外部系統的用戶更新操作不受我們系統的控制，因此可能會造成臟數據被更新到資料庫中。
3、使用悲觀鎖進行控制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現，如Oracle的select.......for update語句，以保證操作最大程度的獨占性。但隨之而來的就是資料庫性能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。如一個金融系統，當某個操作員讀取用戶的數據，並在讀出的用戶數據的基礎上進行修改時（如更改用戶帳戶余額），如果採用悲觀鎖機制，也就意味整個操作過程中（從操作員讀出數據、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態，可以想見，如果面對成百上千個並發，這樣的情況將導致災難性的結果。所以，採用悲觀鎖進行控制時一定要考慮清楚。
死鎖的第三種情況
如果在事務種執行了一條不滿足條件的update語句，則執行全表掃描，把行級鎖上升為表級鎖，多個這樣的事務執行之後，就很容易發生死鎖和阻塞。類似的情況還有當表種的數據量非常龐大而索引建的過少或不合適的時候，使得經常發生全表掃描，最終應用系統會越來越慢，最終發生阻塞或死鎖。
解決方法：
SQL語句中不要使用太復雜的關聯多表的查詢；使用「執行計劃」對SQL語句進行 分析，對於有全表掃描的SQL語句，建立相應的索引進行優化。
***查詢死鎖表以及解鎖表***
通過select * from v$locked_object
可以獲得被鎖的對象的object_id及產生鎖的會話sid，通過查詢結果中的object_id，可以查詢到具體被鎖的對象。
鎖有以下幾種模式:
0：none
1：null 空
2：Row-S 行共享(RS / S鎖)：共享表鎖
3：Row-X 行專用(RX / X鎖)：用於行的修改
4：Share 共享鎖(S)：阻止其他DML操作
5：S/Row-X 共享行專用(SRX)：阻止其他事務操作
6：exclusive 專用(X)：獨立訪問使用
數字越大鎖級別越高, 影響的操作越多。
一般的查詢語句如select ... from ... ;是小於2的鎖, 有時會在v$locked_object出現。
select ... from ... for update; 是2的鎖。
當對話使用for update子串打開一個游標時，
所有返回集中的數據行都將處於行級(Row-X)獨占式鎖定，
其他對象只能查詢這些數據行，不能進行update、delete或select...for update操作。
insert / update / delete ... ; 是3的鎖。
沒有commit之前插入同樣的一條記錄會沒有反應,
因為後一個3的鎖會一直等待上一個3的鎖, 我們必須釋放掉上一個才能繼續工作。
創建索引的時候也會產生3,4級別的鎖。
locked_mode為2,3,4不影響DML(insert,delete,update,select)操作,
但DDL(alter,drop等)操作會提示ora-00054錯誤。
有主外鍵約束時 update / delete ... ; 可能會產生4,5的鎖。
DDL語句時是6的鎖。
以DBA角色, 查看當前資料庫里鎖的情況可以用如下SQL語句：
select object_id,session_id,locked_mode from v$locked_object;
select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time;
如果有長期出現的一列，可能是沒有釋放的鎖。
我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖：
⑥ windows環境下redis集群在分配槽slot失敗
windows環境下redis集群在分配槽slot失敗
通常，為了提高網站響應速度，總是把熱點數據保存在內存中而不是直接從後端資料庫中讀取。Redis是一個很好的Cache工具。大型網站應用，熱點數據量往往巨大，幾十G上百G是很正常的事兒，在這種情況下，如何正確架構Redis呢？
首先，無論我們是使用自己的物理主機，還是使用雲服務主機，內存資源往往是有限制的，scale up不是一個好辦法，我們需要scale out橫向可伸縮擴展，這需要由多台主機協同提供服務，即分布式多個Redis實例協同運行。
其次，目前硬體資源成本降低，多核CPU，幾十G內存的主機很普遍，對於主進程是單線程工作的Redis，只運行一個實例就顯得有些浪費。同時，管理一個巨大內存不如管理相對較小的內存高效。因此，實際使用中，通常一台機器上同時跑多個Redis實例。
⑦ redis cluster 計算slot在哪個節點
假設cluster有5個node，那麼client請求cluster其實是隨機請求了一個節點，假設請求了node1，請求的key經過 CRC16( key ) % 16438會計算出這個key落在哪一個slot上，然後會獲取solt和node的關系，這個關系保存在clusterNode這個數據結構中，如果這個slot在當前node上，就執行命令，否則就返回一個moved信息，主要包括slot和目標node信息，再由client重寫發送請求到目標node。這里在solt遷移的時候，有一個ask重定向。
大概就是這個意思吧，我也不是很清楚，你參考參考吧
網頁鏈接
⑧ 從用戶來看，下面列出的條目中哪些是資料庫管理系統應具有的目標 ①用戶界
[slot].name);printf("Enterstreet:");gets(addr_list[slot].street);printf("Entercity:");gets(addr_list[slot].city);printf("Enterstate:");gets(addr_list[slot].state);printf("Enterzip:");gets(s);addr_list[slot].zip=strtoul(s,'\0',10);}/*Findanunusedstructure.*/intfind_free(void){registerintt;for(t=0;addr_list[t].name[0]&&t=0&&slot
⑨ SQL資料庫中都是以表的形式存儲數據的嗎
SQLSERVER資料庫中數據存儲：
一：存儲文件類型
SQLSERVER有兩種數據存儲文件，分別是數據文件和日誌文件。
其中：數據文件是以8K(＝8192Byte)的頁面(Page)作為存儲單元的。
而日誌文件是以日誌記錄作為存儲單元。本文只討論數據文件的存儲方式，不涉及到日誌文件存儲方式。
數據文件以頁面做為存儲單元存儲數據，要理解數據文件的存儲方式，必須了解SQLSERVER中定義的頁面類型種類。
二：頁面類型
SQLSERVER中頁面類型有8種,具體每種類型的詳細說明，見下圖：
用戶的數據一般存放在數據頁面中,由上圖可以看出,數據頁包含數據行中除 text、ntext 和 image 數據外的所有數據，text、ntext 和 image 數據存儲在單獨的頁中。那麼在一個數據頁面中,數據是如何存放,SQLSERVER又是根據什麼來定位頁面與頁面上的數據呢。要回答這個問題,有必要先了解數據頁面的具體結構。
三：數據頁面結構
在數據頁上，數據行緊接著頁首按順序放置。在頁尾有一個行偏移表。在行偏移表中，頁上的每一行都有一個條目，每個條目記錄那一行的第一個位元組與頁首的距離。行偏移表中的條目序列與頁中行的序列相反。數據頁面結構如下圖所示，下面將詳細解釋
其中：數據頁面頁首：96個位元組，保存著頁面的系統信息，如頁的類型、頁的可用空間量、擁有頁的對象的對象 ID 以及該頁面所屬於哪個物理文件。
數據區：對應於上圖中所有數據行的總區域，存放真正的數據，是以Slot為單位。一個Slot就是對應於一條數據記錄行，從0開始編號,以16進制反序保存,Slot0,Slot1....。
行偏移數組：用於記錄該數據頁面中每個Slot在數據頁面所處的相對位置，便於定位和檢索每個Slot在數據頁面中的位置，數組中每個記錄占兩個位元組。
四：存儲分配單位：盤區(擴展 Extend)
雖然SQLSERVER中數據文件存儲單位是頁面(Page),但實際SQLSERVE並不是為頁面為單位給數據分配空間，SQLSERVER默認的存儲分配單位是盤區。這樣做的主要原因是為了提高性能。為了避免頻繁的讀寫IO，在表或其它對象分配存儲空間，不是直接分配一個8K的頁面，而是以一個盤區(Extend)為存儲分配單位，一個盤區為8個頁面(=8＊8K＝64K)。
但是這樣做雖然減少了頻繁的IO讀寫，提高的資料庫性能，但卻導致出一個新問題，那就是在存儲那些只有少量數據，不足8K的對象，如果也是分配給一個盤區，就會存在存儲空間上的浪費，降低了空間分配效率。
為解決上述問題，SQLSERVER提供了一種解決方案，定義了兩種盤區類型,統一盤區和混合盤區。
其中:統一盤區只能存放同一個對象，該對象擁有這個盤區的所有頁面
混合盤區：由多個對象共同擁有該盤區。
在實際為對象分配存儲盤區時，為了提高空間利用率，默認的情況下，如果一個對象一開始大小小於8個頁面，就盡量放在混合盤區中，如果該對象大小增加到8個頁面後，SQLSERVER會為這個對象重新分配一個統一盤區。
為了能夠通過上述策略來實現為對象分配存儲盤區，SQLSERVER提供了GAM/SGAM機制來管理和維護數據文件的盤區信息。