admin – 第41页

The definition of commercial use is broad, covering more than just obvious ‘profit-making’ uses. In practise, the term is equivalent to income-generating use of any kind, whether direct or indirect.
商业用途的定义非常广泛，其包括绝大部分明显营利的用途。在实践中，不论是直接还是间接地使用任何方式产生收益都等同于商业用途。

Oracle 企业版单CPU 永久授权价格为47,500美元约合人民币285000(按照汇率1:6估算) ，必须购买第一年维保价格为10,450美元约合人民币62700(按照汇率1:6估算)

Oracle 企业版一个named user 永久授权价格为900美元，最低25个named user，约合25*900美元约等于135000人民币（按照汇率1:6估算)，同样必须购买第一年维保

现在Oracle有两种授权方式，按CPU(Process)数和按用户数(Named User Plus)。前一种方式一般用于用户数不确定或者用户数量很大的情况，典型的如互联网环境，而后一种则通常被用于用户数确定或者较少的情况。

按CPU： License数=CPU 数*系数。系数来自Oracle的一个参数表，如IBM Power6的处理器为1，AMD和Intel的处理器为0.5，详细情况见下：

参数	处理器型号
0.25	Sun UltraSPARC T1 处理器
0.50	Sun UltraSPARC T1处理器
0.50	Intel、AMD处理器
0.50	Sun UltraSPARC T2+ 处理器
1.00	IBM POWER6、POWER7 处理器
0.75	其他多核处理器
1.00	单核处理器

则根据公式可以算出，一个SUN UltraSparc T1的4*8核处理器需要4*8*0.25=8个CPU licenses

计算 CPU对应 license数量可以使用下面工具：

按用户数：Oracle用户数的官方定义是每一个访问Oracle数据库的用户，无论是自然人还是设备(如工业环境中的传感器之类)，都算作一个用户(Named User)。

英文官方定义：Named User Plus: is defined as an individual authorized by you to use the programs which are installed on a single server or multiple servers, regardless of whether the individual is actively using the programs at any given time. A non human operated device will be counted.

按用户数购买则对应相应的产品有对应的License的最低购买量限制，如下：

产品	最低License数
Oracle Database Standard Edition ONE	5 Named User Plus licenses
Oracle Database Standard Edition	5 Named User Plus licenses
Oracle Database Enterprise Edition	25 Named User Plus licenses per CPU
Oracle Application Server Standard Edition ONE	5 Named User Plus licenses
All other Oracle Application Server products	10 Named User Plus licenses per CPU

当然用户应该根据自己的实际用户数订购，且不少于相应版本所要求的最低用户数。

一般情况下，1CPU的费用约等于50user的费用，所以如果用户数>CPU数*系数*50，则按CPU订购反而更为经济。

每个License还有有效期的分类[不论是User License还是CPU License]，分别为：1年、2年、3年、4年、5年、永久。当然价格也是依次增加。
以上均为list price 列表价格，具体的discount折扣见shop.oracle.com上的结算或具体代理商的实际折扣。

关于在vmware上Oracle license的计算：

如果Oracle 安装在VMWARE 上，是否也是按照这个方式计算呢？也就是说，在虚拟机VMWARE上Oracle的License计算是否也是按照分配CPU核数来计算的呢？关于虚拟机上ORACLE的License计算，ORACLE 引入了下面 Soft partitioning (软分区)和Hard partitioning (硬分区)概念(如下所示),而且明确规定 VMware是软分区，并且规定Soft partitioning is not permitted as a means to determine or limit the number of software licenses required for any given server。

也就是说在一台物理机上,假如如下所示，虚拟了一台Linux服务器做Oracle Database Server，虚拟了另外一台Windows服务器做SQL Server服务器，物理机上有2个物理CPU，每个4 Core，平均分配给这两个服务器，此时Oracle的License计算是

License Number = 2* 4*0.5= 4 而不是 License Number = 1*4*0.5= 2.

更多信息：

Oracle的许多产品都有分版本，最常见的大致上分成3个版：
企业版Enterprise Edition(EE)
价位最高，全功能、无使用限制。
标准版Standard Edition(SE)
价位中等，主要限制为最大支援4个CPU，且禁止安装到超过4 Socket(CPU插槽)的机器上。
标准版１Standard Edition One(SE1)
价位最低，限制支援２个CPU，且禁止安装到支援超过2 Socket(CPU插槽)的机器上。
Oracle的授权计算方式是採［电脑工作时，命令传送的两个端点］的其中之一，
即User（操作者）或Processor（处理器/CPU）

若採Processor计价
EE版
processor数＝CPU*(Core数/每CPU)*Core_Factor，有小数时无条件进位。假设某Server上：
1CPU，6核，Core_Factor＝0.25
Processor数＝1*6*0.25=1.5->2Processor
2CPU，4核，Core_Factor＝0.5
Processor数＝2*4*0.5=4Processor
SE/SE1版
processor数＝occupied socket＝主机版上有插CPU的socket数，也就是说直接依CPU数计算，
若採User计价
Oracle称此依User计价的方式为Named User Plus License，简称NUP。这里所谓的Named User＝叫得出名字的User，分成两类：
自动设备：
自动运作，且存取Oracle软体。
因为是操作命令的起点，也算是一个Named User；
活人：
有操作电脑并使用到Oracle软体的活人。
至于须有人来操作的设备(PC/NB)则不算。
除计算实际的User外，尚须满足各版本的最低採购量：
EE版：25NUP/Processor
SE/SE1版：5NUP/Socket
这里要注意，NUP是［限软体、限版本、不限Server/Instance］的：
限软体：
Oracle有很多软体，Oracle ERP的NUP不可用于Oracle CRM或其他Oracle的软体。
限版本：
对Oracle的同一个软体而言，SE的NUP不可使用于SE1与EE。也就是说，如果一个User同时会用到SE与EE，则这两版的NUP得各买一份。
但只要［软体＋版本］正确且授权量足够，Oracle不管一个User连上几个Server，也不管你在同一台Server上要跑几份相同的软体。
若直接在shop.Oracle.Com上依台币定价採购Oracle DB，则各版本的入手价(含第１年支援，根据2012.10.29、Shop.Oracle.Com上的台币定价计算)为：
EE版
by Processor(1 Processor)：
1,406,048+309,331
=1,715,379
by NUP(min 25NUP)：
(31,246+6,874)/NUP*25NUP
=38,120/NUP*25NUP
=742,100
SE版
byProcessor(1 Processor)：
575,575+126,627
=702,202
byNUP(min 5NUP)：
(11,512+2,533)/NUP*5NUP
=14,045/NUP*5NUP
=70,225
SE1版
byProcessor(1 Processor)：
190,762+41,968
=232,730
byNUP(min 5NUP)：
(5,920+1,302)/NUP*5NUP
=7,222/NUP*5NUP
=36,110
基本上，当User人数较少时，依NUP授权较为划算。比较费用比例：
EE版：Processor/1NUP＝1,715,379/38,120=45倍
->当每个Processor上的User超过45人时，依Processor计费较实惠
SE版：Processor/1NUP＝702,202/14,045=50倍
->当每个Processor上的User超过50人时，依Processor计费较实惠
SE1版：Processor/1NUP＝232,730/7,222=32.24倍
->当每个Processor上的User超过32人时，依Processor计费较实惠
反之，当人少时应使用NUP计费，若用不上RAC则务必使用SE1。
以一个２００人左右的企业来看，假设：
除了总公司外，另有３个营业点，此公司共架设了４部Server
每部Server都有２CPU，所有CPU均为4Core，且Core Factor均为0.5
公司所有User均使用电脑，且操作的AP均须连上Oracle DB，所有AP不具Oracle特殊授权－＞须有Oracle Database的授权。
则当採购Oracle DB时，依版本及计费方式共有６种价位：
EE：
实际Processor=4Server*2Cpu*4Core*0.5factor=16Processor
实际200NUP，最少NUP=16*25=400NUP，故依400NUP计
byProcessor：
1,715,379*16=27,446,064
byNUP：
38,120*400=15,248,000
SE：
实际Processor=4Server*2Socket=8Processor
实际200NUP，最少NUP=8*5=40NUP，依200NUP计
byProcessor：
702,202*8=5,617,616
byNUP：
14,045*200=2,809,000
SE1：
实际Processor=4Server*2Socket=8Processor
实际200NUP，最少NUP=8*5=40NUP，依200NUP计
byProcessor：
232,730*8=1,861,840
byNUP：
7,222*200=1,444,400
因此，个人的建议是：

仔细试算人数与Processor的比例，如果操作电脑的人员名单明确且人数不多，则务必以NUP计价；但若费用差不多时，依Processor计价比较轻鬆。
千万不可使用Oracle做为公开WebPage的底层，因user不确定有哪些人，计算NUP有困难，Oracle一定会要求依Processor计价。
非必要别招惹EE版，把Core算进来太可怕了。
预算充沛时，把钱花在RAM上，别买太高档的主机板：
若超过2个CPU Socket则Oracle会要求须至少买SE版
若超过4个CPU Socket则Oracle会要求须买EE版
同一软体（例如Oracle DB）不要溷着版本买，最好弄清楚须求一次搞定。如果需求上昇可从SE1变成SE或EE，但＄＄先准备好。
在Oracle.Com中有3份文件最好先看清楚，本文即依此写成：

Core Factor Table
OSIG(Oracle Software Investment Guild)
OLSA(Oracle License and Service Agreement)
Core Factor Table用于计算EE版的版权，其中列出各厂家multi-Core CPU的型号及其Core Factor。注意，上面没写到的型号则CoreFactor=1，也就是说4核的算4个Processor，8核的算8个Processor。

OSIG是Oracle给客户的建议，较易读也有例子。这些例子有几个特徵：

EE版
User众多（数百人）
Processor为单核
算出来好像都是依Processor较便宜，不难看出Oracle比较希望你依Processor买，你轻鬆他Happy。

而OLSA为向Oracle採购时须承认的正式条文，此两份文中对授权规则的描述基本上是相同的，先看清以便谈判。不过OLSA上讲明了Oracle有权来稽核你的使用状况：

会先来书面通知，45天内须配合稽核，Oracle承诺不干扰你日常运作。
稽核时若发现有超用现象，将以书面通知补足授权。
如不配合稽核或补足授权，则Oracle有权中止授权并取消交易（退钱），但是会告你。
就合约内容来看算是公平，但还是要了解计算授权的公式，如果来稽核的人算错了而使你多买，Oracle事后不会退钱的。

参考:

虚拟机VMWARE上ORACLE License 的计算http://www.cnblogs.com/kerrycode/p/3678553.html

http://bbs.chinaunix.net/thread-3633104-1-1.html

http://blog.xuite.net/chiouchienchung/twblog/174429884-%E7%94%B2%E9%AA%A8%E6%96%87Oracle%E7%9A%84%E7%89%88%E6%9C%AC%E8%88%87%E6%8E%88%E6%AC%8A%EF%BC%8C%E4%BB%A5DB%E7%82%BA%E4%BE%8B

Filed Under: Oracle

实习感悟——我的大学不再迷茫

2015/08/21 by admin Leave a Comment

大三暑假，作为一名计算机专业的学生，我开始了在诗檀软件公司的实习工作，如今，为期四十天的实习生活即将结束，回顾实习生活，感触很深，收获颇多。

毕业实习是每个学生走向社会、走上工作岗位必不可少的一个重要环节，通过实习在实践报告中了解社会，让我学到了很多在课堂上根本就学不到的知识，受益匪浅，也打开了视野，增长了见识，为我以后进一步走向工作岗位打下坚实的基础。

公司聚餐合影

处在这个即将步入社会的时期，我也曾跟很多身边的人一样，对未来感到迷茫。在一年前我接触到了oracle后,我就决定我要学习oracle数据库，也算是立志要做一名DBA吧。所以怀着这样的心情，我申请了诗檀软件公司的实习生职位。

刚进入公司的时候，我还在担心自己是否能够胜任这份工作，不过好在刚开始的工作还是比较轻松的，我也慢慢的进入了状态。

实习期间，还参加了甲骨文数据库大会。

甲骨文大会盛况

通过这次的社会实践，我了解到了自己的不足之处，也让我学会了很多东西，我深深地感受到一个人在工作岗位上的那份热情。正因为如此，我才渐渐地懂得了一个道理：要创造自己的事业，就必须付出加倍的努力，凭着一个人对工作的执着，坚定的信念会指引着他走向完美的事业之路。

Filed Under: Oracle

Oracle的损坏/坏块

2015/08/21 by admin Leave a Comment

ORA-1578
ORA-8103
ORA-1410
ORA-1499
ORA-1578
ORA-81##
ORA-14##
ORA-26040
ORA-600 Errors
Block Corruption
Index Corruption
Row Corruption
UNDO Corruption
Control File
Consistent Read
Dictionary
File/RDBA/BL

Error Description Corruption related to:

ORA-1578 ORA-1578一般为Oracle检测到存在物理坏块问题，包括其检测数据块中的checksum不正确，或者tail_chk信息不正确等。 ORA-1578 is reported when a block is thought to be corrupt on read. Block

数据块

OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)” Master Note

OERR: ORA-1578 “ORACLE data block corrupted (file # %s, block # %s)”

Fractured Block explanation

Handling Oracle Block Corruptions in Oracle7/8/8i/9i/10g/11g

Diagnosing and Resolving 1578 reported on a Local Index of a Partitioned table

ORA-1410 ORA-1410错误常见于从INDEX或其他途径获得的ROWID,到数据表中查询发现没有对应的记录。

该错误可能因为数据表与其索引存在不一致，也可能是分区的数据表本身存在问题。
This error is raised when an operation refers to a ROWID in a table for which there is no such row.
The reference to a ROWID may be implicit from a WHERE CURRENT OF clause or directly from a WHERE ROWID=… clause.
ORA 1410 indicates the ROWID is for a BLOCK that is not part of this table. Row

数据行

Understanding The ORA-1410

Summary Of Bugs Containing ORA 1410

OERR: ORA 1410 “invalid ROWID”

ORA-8103 该ORA-8103可能由多个BUG引起，例如LOB在10.2.0.4之前可能会由于BUG覆盖了另一张表的segment header，导致出现ORA-8103错误。

诊断该问题可以从数据表的segment header和data_object_id入手。
The object has been deleted by another user since the operation began.
If the error is reproducible, following may be the reasons:-
a.) The header block has an invalid block type.
b.) The data_object_id (seg/obj) stored in the block is different than the data_object_id stored in the segment header. See dba_objects.data_object_id and compare it to the decimal value stored in the block (field seg/obj). Block

数据块

ORA-8103 Troubleshooting, Diagnostic and Solution

OERR: ORA-8103 “object no longer exists” / Troubleshooting, Diagnostic and Solution

ORA-8102 ORA-8102常见于索引键值与表上存的值不一致。 An ORA-08102 indicates that there is a mismatch between the key(s) stored in the index and the values stored in the table. What typically happens is the index is built and at some future time, some type of corruption occurs, either in the table or index, to cause the mismatch. Index

索引

OERR ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)

ORA-1499 对表和索引做交叉验证时发现问题 An error occurred when validating an index or a table using the ANALYZE command.
One or more entries does not point to the appropriate cross-reference. Index

索引

ORA-1499. Table/Index row count mismatch

OERR: ORA-1499 table/Index Cross Reference Failure – see trace file

ORA-1498 Generally this is a result of an ANALYZE … VALIDATE … command.
This error generally manifests itself when there is inconsistency in the data/Index block. Some of the block check errors that may be found:-
a.) Row locked by a non-existent transaction
b.) The amount of space used is not equal to block size
c.) Transaction header lock count mismatch.
While support are processing the tracefile it may be worth the re-running the ANALYZE after restarting the database to help show if the corruption is consistent or if it ‘moves’.
Send the tracefile to support for analysis.
If the ANALYZE was against an index you should check the whole object. Eg: Find the tablename and execute:
ANALYZE TABLE xxx VALIDATE STRUCTURE CASCADE; Block

OERR: ORA 1498 “block check failure – see trace file”

ORA-26040 由于采用过nologging/unrecoverable选项的redo生成机制，且做过对应的recover，导致数据块中被填满了0XFF，导致报错ORA-26040。 Trying to access data in block that was loaded without redo generation using the NOLOGGING/UNRECOVERABLE option.
This Error raises always together with ORA-1578 Block

数据块

OERR ORA-26040 Data block was loaded using the NOLOGGING option

ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING – Error explanation and solution

ORA-1578 ORA-26040 in a LOB segment – Script to solve the errors

ORA-1578 ORA-26040 in 11g for DIRECT PATH with NOARCHIVELOG even if LOGGING is enabled

ORA-1578 ORA-26040 On Awr Table

Errors ORA-01578, ORA-26040 On Standby Database

Workflow Tables ORA-01578 ORACLE data block corrupted ORA-26040 Data block was loaded using the NOLOGGING option

ORA-1578, ORA-26040 Data block was loaded using the NOLOGGING option

ORA-600[12700] 从索引获得的ROWID，对应到数据表时发现不存在数据行错误。

一把是一致性度consistent read问题
Oracle is trying to access a row using its ROWID, which has been obtained from an index.
A mismatch was found between the index rowid and the data block it is pointing to. The rowid points to a non-existent row in the data block. The corruption can be in data and/or index blocks.
ORA-600 [12700] can also be reported due to a consistent read (CR) problem. Consistent Read

一致性读

Resolving an ORA-600 [12700] error in Oracle 8 and above.

ORA-600 [12700] “Index entry Points to Missing ROWID”

ORA-600[3020] 主要问题是redo和数据块中的信息不一致 This is called a ‘STUCK RECOVERY’.
There is an inconsistency between the information stored in the redo and the information stored in a database block being recovered. Redo

ORA-600 [3020] “Stuck Recovery”

Information Required for Root Cause Analysis of ORA-600 [3020] (stuck recovery)

ORA-600[4194] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch has been detected between Redo records and rollback (Undo) records.
We are validating the Undo record number relating to the change being applied against the maximum undo record number recorded in the undo block.
This error is reported when the validation fails. Undo

ORA-600 [4194] “Undo Record Number Mismatch While Adding Undo Record”

Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter

ORA-600[4193] 主要是redo记录与回滚rollback/undo的记录不一致 A mismatch has been detected between Redo records and Rollback (Undo) records.
We are validating the Undo block sequence number in the undo block against the Redo block sequence number relating to the change being applied.
This error is reported when this validation fails. Undo

ORA-600 [4193] “seq# mismatch while adding undo record”

Basic Steps to be Followed While Solving ORA-00600 [4194]/[4193] Errors Without Using Unsupported parameter

Ora-600 [4193] When Opening Or Shutting Down A Database

ORA-600 [4193] When Trying To Open The Database

ORA-600[4137] transaction id不匹配，问题可能存在与回滚段中或者对象本身存在讹误 While backing out an undo record (i.e. at the time of rollback) we found a transaction id mis-match indicating either a corruption in the rollback segment or corruption in an object which the rollback segment is trying to apply undo records on.
This would indicate a corrupted rollback segment. Undo/Redo

ORA-600 [4137] “XID in Undo and Redo Does Not Match”

ORA-600[6101] Not enough free space was found when inserting a row into an index leaf block during the application of undo. Index

ORA-600 [6101] “insert into leaf block (undo)”

ORA-600[2103] Oracle is attempting to read or update a generic entry in the control file.
If the entry number is invalid, ORA-600 [2130] is logged. Control File

ORA-600 [2130] “Attempt to access non-existant controlfile entry”

ORA-600[4512] Oracle is checking the status of transaction locks within a block.
If the lock number is greater than the number of lock entries, ORA-600 [4512] is reported followed by a stack trace, process state and block dump.
This error possibly indicates a block corruption. Block

ORA-600 [4512] “Lock count mismatch”

ORA-600[2662] 主要是发现一个数据块的SCN甚至超过了当前SCN，常规解决途径有调整SCN等，但11.2以后Oracle公司使较多调整SCN的方法失效了 A data block SCN is ahead of the current SCN.
The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN stored in a UGA variable.
If the SCN is less than the dependent SCN then we signal the ORA-600 [2662] internal error. Block

ORA-600 [2662] “Block SCN is ahead of Current SCN”

ORA 600 [2662] DURING STARTUP

ORA-600[4097] 访问一个回滚段头以便确认事务是否已提交时，发现XID有问题 We are accessing a rollback segment header to see if a transaction has been committed.
However, the xid given is in the future of the transaction table.
This could be due to a rollback segment corruption issue OR you might be hitting the following known problem. Undo

ORA-600 [4097] “Corruption”

ORA-600[4000] It means that Oracle has tried to find an undo segment number in the dictionary cache and failed. Undo

ORA-600 [4000] “trying to get dba of undo segment header block from usn”

ORA-600[6006] Oracle is undoing an index leaf key operation. If the key is not found, ORA-00600 [6006] is logged.
ORA-600[6006] is usually caused by a media corruption problem related to either a lost write to disk or a corruption on disk. Index

ORA-600 [6006]

ORA-600[4552] This assertion is raised because we are trying to unlock the rows in a block, but receive an incorrect block type.
The second argument is the block type received. Block

ORA-600 [4555]

ORA-600[6856] Oracle is checking that the row slot we are about to free is not already on the free list.
This internal error is raised when this check fails. Row

ORA-600 [6856] “Corrupt Block When Freeing a Row Slot

ORA-600[13011] During a delete operation we are deleting from a view via an instead-of trigger or an Index organized table and have exceeded a 5000 pass count when we raise this exception. Row

ORA-600 [13011] “Problem occurred when trying to delete a row”

ORA-600[13013] During the execution of an UPDATE statement, after several attempts (Arg [a] passcount) we are unable to get a stable set of rows that conform to the WHERE clause. Row

ORA-600 [13013] “Unable to get a Stable set of Records”

How to resolve ORA-00600 [13013], [5001]

ORA-600[13030]

ORA-600 [13030]

ORA-600[25012] We are trying to generate the absolute file number given a tablespace number and relative file number and cannot find a matching file number or the file number is zero. afn/rdba/tsn

ORA-600 [25012] “Relative to Absolute File Number Conversion Error”

ORA-600[25026] Looking up/checking a tablespace
invalid tablespace ID and/or rdba found afn/rdba/tsn

ORA-600 [25026]

ORA-600[25027] Invalid tsn and/or rfn found afn/rdba/tsn

ORA-600 [25027]

ORA-600[kcbz_check_objd_typ] 内存中的block buffer检测发现存在错误的object id An object block buffer in memory is checked and is found to have the wrong object id. This is most likely due to corruption. Buffer Cache

ORA-600 [kcbz_check_objd_typ_3]

ORA-600 [kcbz_check_objd_typ]

ORA-600[kddummy_blkchk] ORA-600[kdblkcheckerror] 一种逻辑检测发现问题的情况 ORA-600[kddummy_blkchk] is for 10.1/10.2 and ORA-600[kdblkcheckerror] for 11 onwards. Block

ORA-600 [kddummy_blkchk]

How to Resolve ORA-00600[kddummy_blkchk]

ORA-600 [kdblkcheckerror]

QREF – kddummy_blkchk / kdBlkCheckError – Check Codes Listing (Full) [This section is not visible to customers.]

QREF – kddummy_blkchk / kdBlkCheckError – Check Codes Definition && Return Values[This section is not visible to customers.]

ORA-600[ktadrprc-1] Dictionary

字典

ORA-600 [ktadrprc-1]

ORA-600[ktsircinfo_num1] SYS.SEG$字典表导致row cache字典缓存中存在意外 This exception occurs when there are problems obtaining the row cache information correctly from sys.seg$. In most cases there is no information in sys.seg$. Dictionary

字典

ORA-600 [ktsircinfo_num1]

ORA-600[qertbfetchbyrowid] Row

ORA-600 [qertbfetchbyrowid]

ORA-600[ktbdchk1-bad dscn] This exception is raised when we are performing a sanity check on the dependent SCN and fail.
The dependent scn is greater than the current scn. Dictionary

ORA-600 [ktbdchk1: bad dscn]

Filed Under: Oracle

Oracle用户管理与安全性

2015/08/21 by admin Leave a Comment

Oracle用户管理与安全性

7.1 目标

本节中，您能够：

建立和管理用户
授予用户执行数据库操作的权限
建立和管理角色

7.2 用户与安全性简介

用户会使用您在数据库所建立的用户账户来和数据库连接。用户账户是透过使用者名称来加以识别，同时也定义了下列用户属性：

认证方法
供数据库认证的密码
临时表空间：用来排序操作
预设表空间：当未明确指定表空间时，用于建立表
表空间配额：表空间中的用户表可消耗的空间量
账户锁定

[Read more…]

Filed Under: Oracle

一个大二90后在诗檀软件40天的实习中学到的

2015/08/20 by admin Leave a Comment

一个大二90后在诗檀软件40天的实习中学到的
这次暑期实习，最大的感觉就是充实。
每天充实地工作让人乐观而踏实。

技术方面：

实习过程中，主要围绕12c Data Guard进行：
在这个过程中，从一开始看到ADG white paper如天书，到在不断试验的过程中对它逐渐越来越了解，到可以找出文档中一两处写错的地方，期间的喜怒哀乐也是难以一言以尽之。
几个重要的点是：
1、学会了搭建ADG+Far sync
2、学会了在操作oracle的过程中随时挂着alert日志监控，在搭建ADG的过程中问题检查提供了很大的帮助
3、第一次在九台主机之间搭建一个整体架构
4、掌握了更多Linux管理配置的技巧

能力方面：

1、与人合作解决问题
2、了解了基本的邮件办公交流方式
3、英语阅读能力有所提高
4、独立分析解决问题的能力，在搭建ADG+Far sync的过程中，遇到过很多的问题，有的是粗心导致的，有的是因为基础弱导致的，有的最后发现是软件自身的Bug导致的，但是期间的耐心分析，最后也都一一解决
5、学会规范，规范化文档，规范化

眼界方面：

1、看到了从事Oracle相关工作的真实的样子，这是作为有意以后从事Oracle相关工作的在校生难得可贵的机会
2、了解了Metalink、MOS、以及提SR的流程
3、在从高中时就想来的上海呆了一个多月，感受了在上海生活的一些体验

Filed Under: Oracle