表空间

ORA-00001: 违反唯一约束条件 (.) ORA-00017: 请求会话以设置跟踪事件 ORA-00018: 超出最大会话数 ORA-00019: 超出最大会话许可数 ORA-00020: 超出最大进程数 () ORA-00021: 会话附属于其它某些进程；无法转换会话 ORA-00022: 无效的会话 ID；访问被拒绝 ORA-00023: 会话引用进程私用内存；无法分离会话 ORA-00024: 单一进程模式下不允许从多个进程注册 ORA-00025: 无法分配 ORA-00026: 丢失或无效的会话 ID ORA-00027: 无法删去当前会话 ORA-00028: 您的会话己被删去 ORA-00029: 会话不是用户会话 ORA-00030: 用户会话 ID 不存在。 ORA-00031: 标记要删去的会话 ORA-00032: 无效的会话移植口令 ORA-00033: 当前的会话具有空的移植口令 ORA-00034: 无法在当前 PL/SQL 会话中 ORA-00035: LICENSE_MAX_USERS 不能小于当前用户数 ORA-00036: 超过递归 SQL () 级的最大值 ORA-00037: 无法转换到属于不同服务器组的会话 ORA-00038: 无法创建会话: 服务器组属于其它用户 ORA-00050: 获取入队时操作系统出错 ORA-00051:

这是我离线整理资料里的内容，大概是2012年时候开始使用此性能监控工具的，直到至今，接触到几个性能监控工具里，还是美国quest公司生产的Spotlight此产品相对比较牛！ 我也不知道现在发展到能支持监控多少资源，我就拿我之前整理的文档所对应的的工具版本进行讲解，至于下载软件支持某个资源或者某些资源，请自行百度搜索：quest Spotlight，官网下载的版本是需要收费的，因此自行在网上搜索下载破解版本。 Spotlight可以监控很多很资源，相关如下： Spotlight on web server //web应用程序服务 Spotlight on Active Directory //wwindows操作系统上的AD域应用程序服务 Spotlight on DB2 //DB2关系型数据库应用程序服务 Spotlight on MySQL //mysql关系型数据库应用程序服务 Spotlight on Oracle //oracle关系型数据库应用程序服务 Spotlight on SQL Serever // SQL Serever 关系型数据库应用程序服务 Spotlight on Sybase ASE // sybase OLTP关系型数据库应用程序服务 Spotlight on Unix/Linux //Unix/Linux操作系统 Spotlight on

对事务的提交 MySQL默认是自动提交，而Oracle默认不自动提交，需要手动提交，在写commit指令或者点击commit提交； 分页查询 MySQL是直接在SQL语句中写：select ... from ... where limit x, y实现 而oracle通过用到伪列rownum和嵌套查询 对事务的隔离级别 MySQL是read committed的隔离级别，而oracle是repeatable read的隔离级别 二者都支持serializable串行化事务隔离级别，可以实现最高级别的 读一致性：每个session提交后其他session才能看到提交的更改， Oracle通过在undo表空间为这个session构造它查询时的多版本数据块来实现读一致性，每个session查询时，oracle通过在undo表空间中构造旧版本数据块来实现 MySQL只能支持read committed隔离界别，一个session读取时，其他session不能更改数据，session更新数据时，加上排它锁，其他session无法访问数据 对事务的支持 MySQL在innodb存储引擎的行级锁情况下才能支持事务 Oracle完全支持事务 数据的持久性 MySQL数据库更新或者重启，则完全丢失数据 Oracle通过把sql操作线写入在线联机日志文件中，保存到磁盘上，可以随时恢复 并发性

删除表（记录和结构）的语名delete ———— truncate ———— drop 　　DELETE (删除数据表里记录的语句) www.2cto.com 　　DELETE FROM表名 WHERE 条件; 　　注意：删除记录并不能释放ORACLE里被占用的数据块表空间. 它只把那些被删除的数据块标成unused. 　　如果确实要删除一个大表里的全部记录, 可以用 TRUNCATE 命令, 它可以释放占用的数据块表空间 　　TRUNCATE TABLE 表名; 　　此操作不可回退. 　　相同点 　　truncate和不带where子句的delete, 以及drop都会删除表内的数据 　　注意:这里说的delete是指不带where子句的delete语句 　　不同点: 　　1. truncate和 delete只删除数据不删除表的结构(定义) 　　drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger),索引(index); 依赖于该表的存储过程/函数将保留,但是变为invalid状态. 　　2.delete语句是dml,这个操作会放到rollback segement中,事务提交之后才生效;如果有相应的trigger,执行的时候将被触发. 　　truncate,drop是ddl, 操作立即生效,原数据不放到rollback segment中

目录 配置 参考 配置 [mysqld] port = 3306 socket = /mysql/log/mysql_3306.sock # mysql的目录（即mysql的文件所在目录） # basedir = /mysql/mysql_basedir # mysql中存放数据的目录 datadir = /mysql/data # mysql的日志目录 log_error = /mysql/log/error.log # pid文件所在目录 pid-file = /mysql/log/mysql_3306.pid # mysqld程序在启动后将在给定UNIX/Linux账户下执行; mysqld必须从root账户启动才能在启动后切换到另一个账户下执行; mysqld_safe脚本将默认使用–user=mysql选项来启动mysqld程序。 # user = root # 配置mysql绑定地址，配置为0.0.0.0可以使该机器所有IP访问 bind-address = 0.0.0.0 # mysql标记，一般使用IP最后一位，不可重复 server-id = 1 # 打开binlog log-bin = mysql-bin # binlog的前缀名 log-bin-index = master-bin.index # 更改服务器的校验规则，默认为utf8mb4_general

目录 max_connections connect_timeout interactive_timeout|wait_timeout net_retry_count thread_concurrency thread_cache_size|thread_stack open_files_limit max_connect_errors back_log max_allowed_packet ft_min_word_len auto_increment_increment|auto_increment_offset log_bin_trust_function_creators read_buffer_size performance_schema skip-locking|skip-external-locking skip-name-resolve table_cache init_connect explicit_defaults_for_timestamp transaction-isolation key_buffer_size table_open_cache sort_buffer_size join_buffer_size read_rnd_buffer_size myisam_sort_buffer_size query_cache_size|query

使用过MySQL的同学，刚开始接触最多的莫过于MyISAM表引擎了，这种引擎的数据库会分别创建三个文件： 表结构、表索引、表数据空间 。我们可以将某个数据库目录直接迁移到其他数据库也可以正常工作。然而当你使用InnoDB的时候，一切都变了。 InnoDB 默认会将所有的数据库InnoDB引擎的表数据存储在一个共享空间中： ibdata1 ，这样就感觉不爽，增删数据库的时候，ibdata1文件不会自动收缩，单个数据库的备份也将成为问题。通常只能将数据使用mysqldump 导出，然后再导入解决这个问题。 在MySQL的配置文件[mysqld]部分，增加 innodb_file_per_table 参数。 可以修改InnoDB为独立表空间模式，每个数据库的每个表都会生成一个数据空间。 独立表空间： 优点： 1． 每个表都有自已独立的表空间。 2． 每个表的数据和索引都会存在自已的表空间中。 3． 可以实现单表在不同的数据库中移动。 4． 空间可以回收（除drop table操作处，表空不能自已回收） a) Drop table操作自动回收表空间，如果对于统计分析或是日值表，删除大量数据后可以通过:alter table TableName engine=innodb;回缩不用的空间。 b) 对于使innodb-plugin的Innodb使用turncate table也会使空间收缩。

ORACLE ORA-01653: unable to extend table 的错误 今天用PL SQL Developer往oracle数据库中导入数据时，突然报错，只能终止，错误的具体内容如下： ORA-01653: unable to extend table USER_DATA.JKHDFXJL by 128 in tablespace MSMS 大概意思是说 USER_DATA 表空间不足了，于是google了一下，大概有了些眉目。出现这种表空间不足的问题一般有两种情况： 一种是表空间的自动扩展功能没有开；另一种是空间确实不够用了，已经达到了自动扩展的上限。 所以我们解决问题的步骤就是先查看Oracle数据库表空间大小，然后看一下表空间下的所有的数据文件的自动扩展功能是否打开；若确实是表空间不够用了，那么我们就需要扩大表空间了。 具体步骤如下： 在PL SQL Developer中执行如下SQL语句 SELECT a.tablespace_name "表空间名", a.bytes / 1024 / 1024 "表空间大小(M)", (a.bytes - b.bytes) / 1024 / 1024 "已使用空间(M)", b.bytes / 1024 / 1024 "空闲空间(M)", round(((a.bytes - b.bytes) / a.bytes) *

oracle数据库连接非常慢，sqlplus很快，用客户端就很慢，十几秒才好。然后服务器内存一下就飙升到了90%，最开始以为是表空间占满了，数据库连接数占满了。折腾了半天，重启，还是很慢。应用连接数据库，都启动不了。发现了问题！ 在客户端连接服务器的时候，点击“登录”，需要10秒多钟才可以连接到数据库，连接后操作一切正常。 在客户端用tnsping服务器，如下： C:\Documents and Settings\Administrator>tnsping ORA11G 很长时间没有反应. 终于找到问题所在了:原因在于：！！！！ 这个文件listener.log过大导致oracle像是假死了。listener.org路径：$ORACLE_HOME\diag\tnslsnr\机器名\listener\trace 经确认确实为监听日志过大引起，将监听停止掉，重命名日志文件，重启监听服务，发现新建了日志，连接测试，OK。 原文链接： https://blog.csdn.net/my88star/article/details/75650903 来源： https://www.cnblogs.com/lowezheng/p/11579268.html

转载来自如下 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：https://blog.csdn.net/zejunwzj/article/details/82349839 --Oracle查看表空间大小(单位不是GB) SELECT a.tablespace_name, --表空间名 total, --表空间大小 free, --表空间剩余大小 (total-free), --表空间使用大小 Round((total-free)/total,4)*100 --使用率 FROM (SELECT tablespace_name,Sum(bytes) free FROM DBA_FREE_SPACE GROUP BY tablespace_name) a, (SELECT tablespace_name,Sum(bytes) total FROM DBA_DATA_FILES GROUP BY tablespace_name)b WHERE a.tablespace_name=b.tablespace_name; --Oracle查看表空间当前用户 select username,default_tablespace from user_users; --Oracle查看表所属表空间 SELECT TABLE_NAME