昌哥IT课堂-技能提升|培训认证|数据救援|运维保障 阮胜昌的博客 Linux&MySQL数据库运维

摘要：实际工作中，Oracle中有两个很重要：ServerProcess 和 PGA。 SGA:Shared Global area PGA内存作用和构成 (Private Global Area)一个server process占用一个PGA(内存空间)独占。 1.PGA作用PGA存储与server process相关的一些会话，被单个serverprocess独占2、PGA构成1）private SQL area 2）Session Memory （hold a session’s variables (logon info

摘要：下面的参数设置，对系统的性能会很有帮助。但是建议大家还是结合实际情况使用。APPLIES TO:MySQL Server – Version 5.6 and laterInformation in this document applies to any platform.PURPOSEStrongly recommended initial settingsfor MySQL Server when used for OLTP or benchmarking.SCOPEFor DBAs having OLTP-like workloads ordoing benchmarking.DETAILSWe recomme

摘要：简单来说，学习Oracle数据库就两个目标：保证数据库数据的一致性；(绝对不能出问题)提高数据库的性能（这个和日志没关系）。  读缓存：数据从磁盘上读到内存中，CPU可以读内存中的数据，但CPU执行写时，不会写内存中的数据，要写磁盘上的数据。读缓存只能提高读的性能，对写性能不能提高写缓存：oracle的buffer cache实现了写缓存。写缓存通过日志来实现.  

摘要： Q：current块和cr块区别？A：cr块被构造后被读出，就马上没意义了。。马上就可以被覆盖了。。要修改一个块，只能修改current块。Q：查看一个对象占用了多少不同状态的buffer？注：实验的时候可以先执行 alter system flush buffer_cache;#将buffer cache的内容清空 SYS AS SYSDBA@ORCL>SYS AS SYSDBA@ORCL>selecto.object_name,decode(state,0,'free',1,'xcu

摘要：本章主要阐述SGA中的Database buffer cache。Buffer cache {1.pin (读写瞬间的状态)2.clean3.dirty4.unused(free)}--Database buffer cache概述：1.段、区、块的概念：create table t2 (    id int,    name varchar2(30));建立一个表，同时建立一个段，建立段的同时，会给段分配一个区，区是物理上连续的几个块。区是oracle给段分配的最小单位。块是oracl

摘要：本章主要阐述SGA中的shared pool。Shared pool {1.free2.library cache(缓存sql语句及其执行计划)3.row cache(数据字典缓存)} ps：对Oracle了解的多少的一个重要指标就是看你对数据字典了解多少。 --Shared pooloracle 中只可以整体设置sharedpool的大小，不可以对shared pool中的内存区域分别设置大小。shared pool中容易出问题的是free和library cache；1.free(sha

摘要：1.进程结构图对Oracle生产库来讲，服务器进程（可以简单理解是前台进程）的数量远远大于后台进程。因为一个用户进程对应了一个服务器进程。而且后台进程一般出问题几率不大，所以学习重点也是服务器进程和PGA的关系（容易出问题）。 2.Oracle 实例管理6大共享池，5大后台进程，3大文件控制文件：记录了各文件存放的位置以及当前的运行状态；数据文件：存放数据；重做日志文

摘要：一、Oracle官方支持1.在线官方文档 http://docs.oracle.com/2.metalink.oracle.com，如今已经改成：http://support.oracle.com 二、Oracle数据库管理员的任务设计、实施和维护Oracle数据库时，按优先次序排列的任务包括：1.确定数据库服务器硬件2.安装Oracle软件3.为数据库和安全策略制定计划4.创建、移植和打开数据库5.备份数据库6.登记系统用户和制定用户访问OracleNetw

摘要：收到一个mysql服务器负载告警，上去一看，loadaverage都飙到280多了，用top一看，CPU跑到了336%，不过IO和内存的负载并不高，根据经验，应该又是一起索引引起的惨案了。看下processlist以及slow query情况，发现有一个SQL经常出现，执行计划中的扫描记录数看着还可以，单次执行耗时为0.07s，还不算太大。乍一看，可能不是它引发的，但出现频率实在太高，而且执行计划看起来也不

摘要：不知道你是否遇到过这样的情况，去小卖铺买东西，付了钱，但是店主因为处理了一些其他事，居然忘记你付了钱，又叫你重新付。又或者在网上购物明明已经扣款，但是却告诉我没有发生交易。这一系列情况都是因为没有事务导致的。这说明了事务在生活中的一些重要性。有了事务，你去小卖铺买东西，那就是一手交钱一手交货。有了事务，你去网上购物，扣款即产生订单交易。事务的具体定