今天看到一個網友的提問，在晚上分析了問題之後還是有一些感慨的。 網友的問題做move tablespace的操作時，報了類似下面的錯誤。 alter table a move to users * ERROR at line 1: ORA-14133: ALTER TABLE MOVE cannot be combined with other operations 看到這個問題，第一印象就是常規錯誤，即通過baidu,google,能夠得到一些有用的資訊。這類問題的原因雖然五花八門，但是原理都是類似的。 根據網友的反饋說已經查了些資料，自己就從一些技術角度進行了分析，首先baidu上找了一圈，發現問題發生的原因也確實有不少的場景，檢視metalink，裡面這個問題相關的帖子有3個，比較貼近的就1個帖子，但是裡面描述的問題發生原因竟然是和parallel相關。和這個網友提供的資訊還是有些出入，所以暫時沒有發現有效的資訊輔助。這個時候自己就在想，為什麼我自己做過的move tablespace操作就沒有出現過問題，這個問題發生前的操作和當時的環境是不是也有一定的影響。但是網友提供的就一個簡單的錯誤，自己也著實想了不少的招，自己模擬了quota的問題，模擬了許可權的問題，模擬了表中存在LOB欄位的move操作，甚至模擬了幾個並行的案例，都沒有發現問題，最後還是在一個baidu帖子裡面琢磨那個問題，發現原來是語法的問題。 move_test@TEST11G> alter table a move tablespace move_test_ts; Table altered. move_test@TEST11G> alter table a move users; alter table a move users * ERROR at line 1: ORA-14133: ALTER TABLE MOVE cannot be combined with other operations move_test@TEST11G> alter table a move to users; alter table a move to users * ERROR at line 1: ORA-14133: ALTER TABLE MOVE cannot be combined with other operations

對於這類問題讓人真是感慨，自己發現之後剛要回復給網友時，發現另一個大拿已經回覆了。：） 自我感慨下，一方面也是自己審題不夠認真，兜了一圈發現做了無用功，另外一方面，拋開這個問題，個人覺得提問也確實需要不少的技巧。 在工作中，學習中總避免不了提問，有時候是自己向別人請教，或者反過來人家來問你，這個時候就需要注意提問的一些細節，一定程度上也能夠節省很多的時間，極大地提高效率。 首先關於提問我先說說我的觀點，提問是需要一些基本的技巧的。 提問有兩個邊界，一個是壓根沒有問題，另外一個就是問題太多。 沒有問題的極端 壓根沒有問題也有兩個極端，一個是確實是大牛，已經沒有什麼問題難倒他了，相信越是這樣的人越是謙遜，從我接觸的大牛都是低調行事，感覺他們充滿了神祕感。另外一個邊界就是很多人犯的毛病，壓根沒有問題可提。 記得自己開始工作的時候，很多東西都不熟悉，聽了各種培訓和技術交流，最後在提問環節大家都是保持沉默，很少有人挺身而出。其實這個主要還是態度問題，我最開始工作的一個任務有同事來帶，然後在各種技術稽核中自己都是屬於打醬油的，一直在旁邊，老老實實地按照指示和提示來工作，結果突然有一天，那個同事調到別的專案了，原有的專案堆在了我一個人頭上，這下發現自己還是有很多問題想問，想確認，因為這幾天會有其他的同事在技術稽核中會來問我一些問題，我自己首先得明白透了。這個時候發現工作積極性極大地提高了，當然壓力也很大，回過頭來看那段經歷，發現真是值得，也算是一個機會，讓自己的工作態度發生了很大的改變，很多事情不再是旁觀者清，打打醬油了。自己會換個角度去思考這個問題，發現還是受益匪淺。 問題太多的極端 比如剛工作的時候，會碰到不少的細節問題，比如環境問題，資料問題，業務問題，開發問題等等。 如果你反覆這樣問客戶，客戶會認為你不夠專業，如果你反覆這樣問同事，如果大家都在緊張的工作，一會一個問題就好像給其他人的工作中加入了一個又一個斷點，比如幾分鐘內你丟擲了十多個問題，相信耐性再好的人在幾輪折磨後也會直接間接的向你抗議。這種情況下還是建議能夠把問題整理一下，然後在一個集中的時間段內提問解決。Oracle資料庫中也是這麼幹的，你所做的很多資料操作，也不是完全實時同步到資料檔案裡，也都是由dbwr來做非同步的資料批量寫入。 自己在平時也會接到網友的提問，但是有時候看到有些問題自己就更加迷茫了甚至無奈，因為有的問題完全可以通過baidu,google來完成，比如有的朋友問我，使用mysql建立儲存過程的語法是什麼樣的，這個時候自己有些無奈，不過還是會盡量耐心的回覆。比如這個問題我是這樣答覆的：如果不夠確定可以通過網路來得到答案，在一些技術帖子中會有相關的語法解析。如果手頭有現成的環境可以使用下面的命令即可完成。如果想得到更加全面的文件內容，可以在mysql的官方網站中得到答案，內容也是大同小異。 mysql> help create procedure Name: 'CREATE PROCEDURE' Description: Syntax: CREATE [DEFINER = { user | CURRENT_USER }] PROCEDURE sp_name ([proc_parameter[,...]]) [characteristic ...] routine_body 還有些朋友可能對我期望有些高，比如有的網友問我類似下面的問題:mysql中的表名最大支援是多少個字元，這類問題我一般都會反問他，你自己有環境嗎，自己在本地測試過嗎，一般都會得到否定回答，我會把答案告訴他，然後希望他下一次自己來實踐。 所以大家都會有這樣感受，在QQ群，微信群中提問一些細節問題得到的回覆都比較少，很長時間都沒有人回覆，而一旦有人決定幫助你的時候，一般都會讓你提供更加詳細的資訊，甚至日誌。這些僅僅靠提供一個ora錯誤來獲得準確的答案還是挺有風險的。 不管怎麼樣，提問都是希望問題能夠得到解答，問題的輕重緩急我們也需要衡量一下，其實有些問題解決了之後，一些相關的問題也會觸類旁通的解決。完全沒有必要再做一次這樣的努力。 在個人堅持寫微信公眾平臺文章的時候，得到了不少網友的支援和幫助，我的朋友給我建議文章的格式問題，有的對內容中出現的錯別字給出了提示和指正，有的朋友還給了不少圖片的連結作為每天筆記的縮圖。還有的朋友對文章中的一些技術細節和我探討，非常感謝大家，其實都是提問讓自己得到提高，在分享答案的同事，我們都從中感受到了那種無私的溫暖。