Oracle KVM:Storage Pool的狀態是locked

 

  • 記錄一下發現其中一個VM在關機後沒有辦法重啟,錯誤訊息是說Storage Pool目前是inactive
  • 按下activate的按鈕後,Activate的task一直在跑,無法成功或結束,只好以SSH登入KVM Manager主機,以指令取消Task:
  • Task取消後,Storage Pool的狀態變成locked,檢查log也沒有看到什麼特別的錯誤
  • 因為檢查不出來哪裡有問題,只能找高手幫忙,他的做法跟我在網上找到的討論相似,強制更新資料庫的值來改變狀態,當然執行前要先檢查系統的log。
  • 以SSH登入KVM管理主機,執行下列指令登入PostgreSQL(Oracle Linux KVM):sudo -u postgres psql engine
  • 檢查一下目前的狀態,SQL:select id,storage,storage_name,storage_pool_id,status from storage_domains;,結果目前status的值是5,也就是locked
  • 我在網上找到的文章是更改storage_domains,SQL如下:update storage_domains set status=1 where id= ;

    但是會出現無法更改的警告:To enable updating the view, provide an INSTEAD OF UPDATE trigger or an unconditional ON UPDATE DO INSTEAD rule

  • 改用這個SQL檢查一下狀態:SELECT * FROM storage_pool_iso_map,status一樣是5
  • 強制更改狀態,SQL:UPDATE storage_pool_iso_map SET status = 1 WHERE storage_id =
  • 重新查詢Storage_pool_iso_map的status,發現已成功更改為3
  • 重啟一下服務:systemctl restart ovirt-engine,再到網頁版管理介面查看Storage Pool的status,現在變成active了,試著啟動vm也成功了。
  • 修改資料庫算是危險的動作,建議還是找專人來處理比較好,這裡僅記錄一下,也許以後自己建KVM測試區時可以試一試。

Window 10利用PowerShell來關閉IPv6

 今天被要求先關掉自己電腦的IPv6,因為微軟有發佈漏洞,因為沒有使用IPv6,所以關掉也沒有什麼影響。


最簡單的方式是用網卡的內容取消勾選「網際網路通訊協定第 6 版 (TCP/IPv6)」,而這次試用PowerShell來關掉IPv6,先輸入下列的指令,找出所有的網路適配器

Get-NetAdapterBinding -ComponentID ms_tcpip6


由上圖可以發現,目前我的電腦中只剩下「乙太網路 2」還有啟用IPv6,於是執行下列的指令來關閉IPv6

Disable-NetAdapterBinding -Name "乙太網路 2" -ComponentID ms_tcpip6


再執行一次檢查的指令,就可以發現「乙太網路 2」的IPv6也被關閉了。

FRM-40654: Record has been updated. Requery block to see change

 Oracle的ERP在客戶基本檔的from出現一個錯誤: FRM-40654: Record has been updated. Requery block to see change

一開始以為是有 Table Lock,但是查了一下,並沒有發現有Table Lock的現象,而且只有單一客戶的資料會有這個問題,最後發現是相關的 Table中,有一個欄位的資料前後有空白造成的,更新資料就解決了。

簡單紀錄一下,下次再出現時就知道如何解決了。

利用指令typeperf來監控Windows的效能

 

[[Windows]] 有一個可以取得效能監控的指令:typeperf,就像是「控制台」->「系統管理工具」->「效能監視器」,只是效能監視器是圖形介面,typeperf則是CSV格式輸出文字。typeperf還允許加上 -si 來指定秒數; -sc 指定取樣次數,再加上 -o 可將結果存成文字檔。



語法如下,例如想要取得CPU的使用率,可以使用指令:typeperf Processor(_Total)% Processor Time
	  typeperf  [options]
	  typeperf -cf  [options]
	  typeperf -q [object] [options]
	  typeperf -qx [object] [options]	  
	  註: 參數是效能計數器的完整名稱,格式為 \Computer\Object(Instance)\Counter,例如"Server_Name\Processor(1)\% User Time"。
可用效能監視器來取得,下面有兩個範例

第一個範例是我想要取得CPU的使用率,由下圖可知Processor計數器有數種參數,我的選擇是「% Processor Time」,而例項則表示我有4個Core,而「_Total」則是全部


所以指令組成如左: typeperf "Processor(_Total)% Processor Time",結果如下圖


第二個範例是要監控chrome瀏覽器其中的一個Thread,如下圖


所以指令的組成如左:typeperf "Thread(chrome/20)Elapsed Time",其結果如下圖:


另外typeperf也可以一次取得多個監控數值,但是要把欲監控的項目寫在一個文字檔(test.txt)內如下:


接著我們將指令改為讀取文字檔:typeperf -cf test.txt -si 1 -sc 10,每一秒會監控一次,一共取樣10次,其結果如下:


D3.js如何選擇上一階元素(Panent Node)

先來看下列 d3.js 的程式碼,我要產生兩個不同大小、顏色的圓形

svg_test03 = d3.select("#svg_test03")
svg_test03_g = svg_test03.append('g')

svg_test03_g
  .append('circle')
  .attr('cx', 80 )
  .attr('cy', 60)
  .attr('r', 50)
  .attr('fill','#ff0000')
  .append('circle')
  .attr('cx', 80 )
  .attr('cy', 60)
  .attr('r', 40)
  .attr('fill','#ffffff')


其產生的svg碼如下,第二個圓被包在第一圓的程式碼之中,顯然這並不符合我們的需求,實際上第二個圓在網頁上也是沒有顯示出來




我們要的結果應該是兩個圓形都要在<g>元素底下才對。我們修改一下程式碼,讓第二個圓在新建時應該先取得上一階元素(<g>)

svg_test03_g
  .append('circle')
  .attr('cx', 80 )
  .attr('cy', 60)
  .attr('r', 50)
  .attr('fill','#ff0000')
  .select(function() { return this.parentNode; }) //取得上一階元素
  .append('circle')
  .attr('cx', 80 )
  .attr('cy', 60)
  .attr('r', 40)
  .attr('fill','#ffffff')


利用this.parentNode來取得上一階元素後再增加第二個圓,此時svg才會符合我們的期待,網頁上也才能正確顯示兩個圓形




如果要取得上二階的元素時,可以使用兩次的this.parentNode:

.select(function() { return this.parentNode; }) 
.select(function() { return this.parentNode; }) //利用兩次來取得上兩階的元素



 之前用 [[d3.js]] 測試綁定資料時,都是參考網路上的教學,也都是比較簡單的單一元素,今天測試如果我的圖形需要多個圖層元素組合而成,那應該要如何做呢?

一開始我的想法是用function,把圖層元素組合的程式包成一個function,接著將元素的一些參數都改成變數,要產生幾個就呼叫幾次function,這樣的做法測試是可行的。

雖然用function可以解決,但是好像不符 [[D3.js]] 的理念,所以又在網路上多多學習,果然是我對它不夠了解,沒有用到它精華的地方。

這次測試的想法是,我有兩個圓,外圓比較大,內圓比較小且是白色的,所以兩個圓疊起來就像是一個甜甜圈,而我想要產生三個甜甜圈,而這三個甜甜圈有不同的大小與顏色。

測試成功的程式碼如下:

HTML:
<div>
    <svg id="svg_test02" width="500" height="300"></svg>
</div>

Javascript:

// circle_cx是圓心x的座標位置;circle_r_o是外圓的半徑;circle_r_i是內圓的半徑;fill_d是外圓的顏色
json_text02 = [ 
  {"circle_cx": 80,"circle_r_o": 50,"circle_r_i": 40,"fill_d":"#FF0000"},
  {"circle_cx": 200,"circle_r_o": 60,"circle_r_i": 50,"fill_d":"#00FF00"},
  {"circle_cx": 350,"circle_r_o": 70,"circle_r_i": 60,"fill_d":"#0000FF"} ]

svg_test02 = d3.select("#svg_test02")

//先產生多個<g>,因為陣列有3個元素,所以會新增3個新的<g>。因為實際沒有元素,所以要用.enter()增加<g>元素
svg_test02_g = svg_test02.selectAll('g').data(json_text02).enter().append('g') 

//選擇所有的<g>,並增加外圓,因為實際沒有元素,所以要用.enter()
svg_test02_g           
  .selectAll('g')
  .data(json_text02) 
  .enter() 
  .append('circle')
  .attr('cx', (d) => { return d.circle_cx} )
  .attr('cy', 150)
  .attr('r', (d) => { return d.circle_r_o})
  .attr('fill',(d) => { return d.fill_d })

//選擇所有的<g>,並增加內圓,因為實際沒有元素,所以要用.enter()
svg_test02_g           
  .selectAll('g')
  .data(json_text02)
  .enter() 
  .append('circle')
  .attr('cx', (d) => { return d.circle_cx} )
  .attr('cy', 150)
  .attr('r', (d) => { return d.circle_r_i})
  .attr('fill','#ffffff')  //固定白色

執行結果如下:











 最近遇到一個問題,在觀察Oracle DB 11g時,發現Undo Tablespace使用率有65%,約佔37GB,所以查了一下是哪一個Session在佔用。但是卻發現所有的Session都沒有佔用大量Undo的情形,這就奇怪了。

先用下列的SQL查詢一下Undo Tablespace的使用狀況,發現UNEXPRIED的值很高

select DISTINCT STATUS "狀態", COUNT(*) "EXTENT數量",
       SUM(BYTES) / 1024 / 1024 / 1024 "UNDO大小(GB)"
  FROM DBA_UNDO_EXTENTS
  GROUP BY STATUS;

查session使用undo空間量,發現沒有特別的session佔用大量的undo

select s.sid, substr( s.program, 1, 15 ) program,
s.machine,t.xidusn || '.' || t.xidslot || '.' || t.xidsqn tx_addr,
t.status, t.start_time, tbs.tablespace_name tbs_name,
round( t.used_ublk * tbs.block_size /1048576, 2 ) undo_size_mb,
t.used_urec
from v$transaction t, v$session s, v$parameter p, DBA_tablespaces tbs
where t.ses_addr = s.saddr
and p.name = '<UNDO_TABLESPACE_NAME>'
and p.value = tbs.tablespace_name
order by t.used_ublk desc;


在網路找了許多的文件後,原來在Oracle 10gR2之後,預設會啟用automatic undo management(AUM)功能,在Undo Tablespace對應的Data File不是自動擴充,且Undo空間又比較大的時候,tuned_undoretention的值是根據UNDO表空間大小的百分比来計算的,在一些情况下會將tuned_undoretention的值調整得特别大。換句話說,就是自動加大Undo的保留時間。

先看一下DB設定的undo_retention,得到的是10800秒;






接著依下列的SQL,看看tuned_undoretention的變化,結果出現了90031秒

select maxqueryid ,to_char(begin_time, 'DD-MON-RR HH24:MI') begin_time,
to_char(end_time, 'DD-MON-RR HH24:MI') end_time,tuned_undoretention
from v$undostat order by end_time desc;









由上面的結果可以推論,因為保留時間變長了,導致現在的Undo Unexpired的值很多,不過在文件中有提到雖然Undo的空間使用率很滿,但是如果有Session遇到真的要使用空間時,會自動調整tuned_undoretention來釋放空間。


另外,由MAXQUERYID這個欄位可以得知是哪一個SQL需要較長的tuned_undoretention,由下列的SQL來找出來:

select * from v$sqltext where sql_id='2jxkb8q6sxua9' order by piece ;


查詢之後發現這個SQL就是我之前有看到因為執行很久,結果產生ora-01555的那個SQL,從v$session找一下現在是不是還有Session正在執行這個SQL,結果發現有兩個正在執行。於是我就將這兩個Session刪掉後,再重新觀察tuned_undoretention,可以發現tuned_undoretention的值變小了,而Undo可用的空間也變大了。