关于提问的一些建议

今天看到一个网友的提问，在晚上分析了问题之后还是有一些感慨的。
网友的问题做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错误来获得准确的答案还是挺有风险的。
不管怎么样，提问都是希望问题能够得到解答，问题的轻重缓急我们也需要衡量一下，其实有些问题解决了之后，一些相关的问题也会触类旁通的解决。完全没有必要再做一次这样的努力。
在个人坚持写微信公众平台文章的时候，得到了不少网友的支持和帮助，我的朋友给我建议文章的格式问题，有的对内容中出现的错别字给出了提示和指正，有的朋友还给了不少图片的链接作为每天笔记的缩略图。还有的朋友对文章中的一些技术细节和我探讨，非常感谢大家，其实都是提问让自己得到提高，在分享答案的同事，我们都从中感受到了那种无私的温暖。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1661304/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-1661304/