Monthly Archives: January 2016
SQLSERVER的CTE递归查询
SQLSERVERCTE递归查询，虽然语法上比Oracle的麻烦一些，但本身比较简单，下面这个例子主要是取出顶层节点、层级数，额外增加了一点代码 创建测试表： 插入测试数据 查询语句： 运行结果： start_id id name pid level A1 A1 公司1 A 1 A2 A2 公司2 A 1 A2 A21 公司2-部门1 A2 2 A2 A22 公司2-部门2 A2 2 A1 A11 公司1-部门1 A1 2
PL/SQL的常用设置
一、显示所有打开的窗口，并永久生效 菜单：Tools -> Window List 菜单：Window -> Save Layout 二、默认显示My Objects，提高数据库对象的展开速度 菜单：Tools -> Browser Filters，将My Objects设置为默认 三、调整数据库对象的显示顺序，最常用的放在前面 菜单：Tools -> Browser Folders 建议显示顺序为：Recent Objects | Tables | Sequences | Views | Tablespaces | Fucntions | Procedures | Tiggers | Database Links | Jobs | Users | Recycle bin，其他顺序不变，可以根据自己的习惯调整。 四、编辑器设置：关键字自动转化为大写 菜单：Tools -> Preferences -> User Interface -> [...]
[转]TCP的三次握手和四次分手
原文地址：简析TCP的三次握手与四次分手 下面是最核心的一张图： 三次握手过程 第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认； 第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。 四次分手过程 当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，肯定是要断开TCP连接的啊。那对于TCP的断开连接，这里就有了神秘的“四次分手”。 第一次分手：主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了； 第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我也没有数据要发送了，可以进行关闭连接了； 第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入CLOSE_WAIT状态； 第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。
按照SQL的方式操作PLSQL中的集合变量
直接上程序代码，唯一感觉不爽的地方就是集合类型要在数据库级别定义。根据ORACLE PL/SQL Programming书上的介绍，在Oracle 12c中，table语句支持在package中定义的集合变量，因无12c的环境尚未实际验证。 定义数据库级别的对象和集合类型 使用table语句，让oracle将集合在系统内容转换为虚拟的数据库表，然后可以用sql的方式操作集合变量
Oracle存储中的集合类型测试
主要测试了Associative array和Nested Table两种类型。
Oracle存储过程中的ORA-01031错误分析
在调用存储过程中，需要使用EXECUTE IMMEDIATE的方式动态创建临时表，运行的时候发生了下面的错误： 但奇怪的是，同样的语句，在SQL窗口执行正常。 这种现象的原因，涉及到Oracle对用户权限的处理，在Oracle中用户的权限分为三类： 1. 系统权限：对于数据库某一类对象的权限，如创建表、更改表等操作，具体的权限清单可以在SYSTEM_PRIVILEGE_MAP表中查询到。 说明：权限的名称中如含有ANY，表示权限不限当前的Schema。 2. 对象权限：对于特定数据库对象（如表、视图、、触发器、函数、存储过程等）的权限（如SELECT、INSERT、UPDATE、DELETE等），授权方式为： 3. 角色权限：用户的系统权限和对象权限都是直接赋予用户的，为了简化权限的管理，可以把相同的权限赋予某个角色，然后把角色赋予用户，这样用户就间接的拥有了角色的权限。Oracle默认已经设置了几个角色，常用的是CONNECT、RESOURCE、DBA等。 调用存储过程中的权限机制，根据网上的资料分析总结，在存储过程的内部，用户所具有的权限是存储过程的Owner的系统权限和对象权限，不包括角色权限。 在最前面所说的问题，就是用户创建表的权限是在角色权限中，所以在SQL窗口中可以执行，但在存储过程中无法执行。 处理方法： 1. 在存储过程的声明语句增加AUTHID CURRENT_USER语句，Oracle判断存储过程权限变为调用者的所有权限,不再是存储过程Owner的权限。 2. 给用户增加CREATE TABLE的系统权限 权限相关的表： 用户拥有的系统权限 USER_SYS_PRIVS 用户拥有的对象权限 USER_TAB_PRIVS 用户拥有的角色 USER_ROLE_PRIVS 系统内的角色 DBA_ROLES 角色拥有的系统权限 ROLE_SYS_PRIVS 角色拥有的角色权限 ROLE_TAB_PRIVS 权限清单 SYSTEM_PRIVILEGE_MAP 参考资料： Oracle 用户、对象权限、系统权限
Feed订阅