一、引言
大家好,我叫张小念(小名念念),家里人都叫宝儿。
一个java
两年半的练习生,经历了起起伏伏的疫情时代,终于在java
一行也算是入了门。
但是,计划永远赶不上变化,
有一天经理突然发消息说:“哎呀,疫情时代没赚到钱,部门要裁一批人… ”
巴拉巴拉说了一大堆,也就是说念念也没有抵得了这波潮~
小念心想:哇靠,疫情的时候这么难都没裁人,咋还放开了还润了…
管他呢,拿了补偿直接出去旅游,先玩了再说…
就这样,小念同学在这2个月去了苏州,大理 又趁着空隙回了趟老家…
终于,2个月后的某一天,小张同学终于想着要找工作了,
说干就干,直接上招聘软件开聊约面试
…
就这样找了两个月,也去了面试,一共也就5家面试。
毕竟张同学的简历是中途转行自学进来的,现在的招聘软件第一条就是计算机专业…所以很多家公司连面试的机会都没有。
在这样不找工作,直接吃老本了,这个时候,小张已然有点着急了。
赶紧在群里面问问最近有小伙伴再找工作吗?
嘿,没想到还真有~
详细一聊发现,这孩子已经找了半年了,张小念瞬间觉得自己又行了,赶紧躺着开了一局王者农药~
…
又过了大半个月,终于在家里面的催促,疯狂投递简历
只要是计算机行业的,投!再投!疯狂投!
几天之后,念宝无意又仔细的阅读了这篇巨大的招聘要求,此时心里只有一句
因为这个招聘要求是:
1.踏实肯干,抗压能力强
2.熟练使用维护Oracle数据库
3.精通Linux,Unix
4.熟练使用C#,Java语言
5.熟练shell脚本
…
念念心想,这尼玛要求太高了, 我就是个初级…
就在念念陷入绝望之际,奇迹出现了------几天之后那边的HR打电话询问念念啥时候能过去面试一下。
这有面试还说啥,直接开干,面试的结果居然也出乎意料,当即就要求他第二天就来上班。
这念念回家不时的掐一下自己,在现在互联网如此恶劣的情况下,这个面试竟然这么快就拍板了~
二、开干:数据字典应用实例
念念上班的第一天,公司的部门主管见了他,并让他进行一个月的试用期工作,跟他说:
“考虑到你刚来公司,这一个月给你安排一点轻松的活,主要是想要让你熟悉一公司的数据库系统,因此你这一个月主要是把公司的Oracle数据库的配置和结构等做成文档发给我。”
这一个有一个惊喜,直接把念念干晕了,这真的是祖宗显灵了~
但是一开始工作念念就遇到了麻烦,发现前任DBA早已离开了公司,而且啥资料都没有留下,真的是干干净净的来,干干净净的走啊。而且很多工作是由公司的It来做的,但是公司没有设置这一职位,所以很多工作都是要从头开始,而且就只有念念一个人开干。
不管怎样,还是要干的不是吗?公司已经提供了平台,就算念念之前没搞过Oracle现在也得连夜学习突击,硬着头皮上了。
直接先链接到数据库,链接之后
先想着拿到公司Oracle数据库的基础信息
于是念念想到了数据字典v$database
SELECT name,created,log_mode,open_mode from v$database;
NAME | CREATED | LOG_MODE | OPEN_MODE |
---|---|---|---|
HELOWIN | 2016/1/4 1:28 | NOARCHIVELOG | READ WRITE |
此时:
念念发现,公司数据库名字叫helowin
,创建时间居然是2016年,数据库运行模式在归档模式
,数据库的状态是可读可写【也就是正常状态】。
之后想着看看Oracle运行在的计算机的主机名字,实例名和oracle数据库的版本。
SELECT host_name,instance_name,version FROM v$instance;
HOST_NAME | INSTANCE_NAME | VERSION |
---|---|---|
d26786b358b3 | helowin | 11.2.0.1.0 |
这个时候晓得了运行在d26786b358b3
这个机器上面,实例名字还是helowin,后面是版本号。
因为公司购买了一些商业软件,这对Oracle数据库管理系统有一些特殊的要求,于是念念利用数据字典v$version继续发起了查询
SELECT banner FROM v$version
BANNER |
---|
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production |
PL/SQL Release 11.2.0.1.0 - Production |
CORE |
TNS for Linux: Version 11.2.0.1.0 - Production |
NLSRTL Version 11.2.0.1.0 - Production |
显示的是一些信息。
接下来利用数据字典来获取控制文件的名字
SELECT name FROM v$controlfile
NAME |
---|
/home/oracle/app/oracle/oradata/helowin/control01.ctl |
/home/oracle/app/oracle/flash_recovery_area/helowin/control02.ctl |
这里可以清楚的看到,数据库有两个控制文件,放在了同一个磁盘下的不同目录。
为了获取公司Oracle数据库的重做日志和配置信息
念念想到了数据字典v$log.
SELECT group#,members,bytes,status,archived FROM v$log
GROUP# | MEMBERS | BYTES | STATUS | ARCHIVED |
---|---|---|---|---|
1 | 1 | 52428800 | INACTIVE | NO |
2 | 1 | 52428800 | CURRENT | NO |
3 | 1 | 52428800 | INACTIVE | NO |
这个时候,宝儿看到了oracle一共有三组重做日志,
每个重做日志组中只有一个成员,
每个重做日志成员大小为50MB,都没有被归档【ARCHIVED=no】
数据库当前正在操作的重做日志为2组【STATUS=CURRENT】
当然他也想知道每个重做日志【成员】文件所存放的具体位置。
于是他又想到了数据字典v$logfile。
SELECT group#,member FROM v$logfile
GROUP# | MEMBER |
---|---|
3 | /home/oracle/app/oracle/oradata/helowin/redo03.log |
2 | /home/oracle/app/oracle/oradata/helowin/redo02.log |
1 | /home/oracle/app/oracle/oradata/helowin/redo01.log |
这个时候就是显示的存放地址了。
为了评估公司的Oracle数据库的备份和恢复策略并确定归档文件的操作位置
archive log list
如果这个命令报错的话,查看一下这个文章解决问题。
解决办法:亲测好用
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 24
Current log sequence 26
接下来,念念又想知道公司的Oracle数据库到底有多少表空间以及每个表空间的状态,这个时候,他想起来数据字典dba_tablespace。
于是:
SELECT tablespace_name,block_size,status,contents,logging FROM dba_tablespaces;
SYSTEM | 8192 | ONLINE | PERMANENT | LOGGING |
---|---|---|---|---|
SYSAUX | 8192 | ONLINE | PERMANENT | LOGGING |
UNDOTBS1 | 8192 | ONLINE | UNDO | LOGGING |
TEMP | 8192 | ONLINE | TEMPORARY | NOLOGGING |
USERS | 8192 | ONLINE | PERMANENT | LOGGING |
EXAMPLE | 8192 | ONLINE | PERMANENT | NOLOGGING |
WATERBOSS | 8192 | ONLINE | PERMANENT | LOGGING |
DOG_DATA | 8192 | ONLINE | PERMANENT | LOGGING |
由此可见,一共有7个表空间,数据大小都为8KB,
都是联机状态,除了TEMP
和EXAMPLE
这两个表,其他的都受重做日志的保护!
其中temp为临时表(排序时用),而UNDOTBS1
为还原表空间,其他都是永久的表空间。
当念念以及知道以上表空间的信息之后,
他当然也想了解每个表存放在哪个磁盘上面以及文件的名字等信息。
此时他想起来数据字典【dba_data_files】
SELECT file_id,file_name,tablespace_name,bytes/1024/1024 MB FROM dba_data_files;
FILE_ID | FILE_NAME | TABLESPACE_NAME | MB |
---|---|---|---|
5 | /home/oracle/app/oracle/oradata/helowin/example01.dbf | EXAMPLE | 100 |
4 | /home/oracle/app/oracle/oradata/helowin/users01.dbf | USERS | 5 |
3 | /home/oracle/app/oracle/oradata/helowin/undotbs01.dbf | UNDOTBS1 | 95 |
2 | /home/oracle/app/oracle/oradata/helowin/sysaux01.dbf | SYSAUX | 680 |
1 | /home/oracle/app/oracle/oradata/helowin/system01.dbf | SYSTEM | 690 |
6 | /home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/c:waterboss.dbf | WATERBOSS | 100 |
7 | /home/oracle/app/oracle/product/11.2.0/dbhome_2/dbs/c:dogdata.dbf | DOG_DATA | 100 |
上述结果显示了文件名,文件的位置,以及文件的所属空间,最后那个大小,就是把字节变成MB显示最后的单位也是MB咯。
最后,念宝儿想知道公司的oracle数据库系统上到底有多少用户和什么时候创建。
这个时候字典表就是dba_users;
于是
SELECT username,created FROM dba_users;
USERNAME | CREATED |
---|---|
WATERUSER | 2023/5/25 15:43 |
DOG | 2023/5/30 15:32 |
SYSMAN | 2009/8/15 0:40 |
SYSTEM | 2009/8/15 0:17 |
SYS | 2009/8/15 0:17 |
MGMT_VIEW | 2009/8/15 0:42 |
DBSNMP | 2009/8/15 0:24 |
SPATIAL_WFS_ADMIN_USR | 2009/8/15 0:39 |
SPATIAL_CSW_ADMIN_USR | 2009/8/15 0:40 |
HR | 2014/8/23 6:26 |
APEX_PUBLIC_USER | 2009/8/15 0:43 |
OE | 2014/8/23 6:26 |
DIP | 2009/8/15 0:19 |
SH | 2014/8/23 6:26 |
IX | 2014/8/23 6:26 |
MDDATA | 2009/8/15 0:36 |
PM | 2014/8/23 6:26 |
BI | 2014/8/23 6:26 |
XS$NULL | 2009/8/15 0:31 |
ORACLE_OCM | 2009/8/15 0:19 |
SCOTT | 2009/8/15 0:50 |
OLAPSYS | 2009/8/15 0:36 |
SI_INFORMTN_SCHEMA | 2009/8/15 0:31 |
OWBSYS | 2009/8/15 0:49 |
ORDPLUGINS | 2009/8/15 0:31 |
XDB | 2009/8/15 0:29 |
ANONYMOUS | 2009/8/15 0:29 |
CTXSYS | 2009/8/15 0:29 |
ORDDATA | 2009/8/15 0:31 |
OWBSYS_AUDIT | 2009/8/15 0:49 |
APEX_030200 | 2009/8/15 0:43 |
APPQOSSYS | 2009/8/15 0:24 |
WMSYS | 2009/8/15 0:25 |
EXFSYS | 2009/8/15 0:29 |
ORDSYS | 2009/8/15 0:31 |
MDSYS | 2009/8/15 0:31 |
FLOWS_FILES | 2009/8/15 0:43 |
OUTLN | 2009/8/15 0:17 |
三、新的开始
经过不懈努力,张小念终于把公司的数据库的基本结构摸清楚了,
然后他就开始写了他人生中也是公司有史以来第一份Oracle数据库文档。
他用了两周多的时间完成了这里程碑式的意义的重要文档,其中当然自己也添加了很多精彩的分析和注释。
交给经理的时候,经理满意的点了点头。
这个时候,宝儿知道了,他的暂时性危机算是解除了,接下来的路将更为凶险…
但是,Java练习生有什么可以畏惧的呢? 小张这样想到…
ok 那先这样