Author: mac

Bug 12633340 – RISK SESSION SPIKE – LIBRARY CACHE LOCK AND LIBRARY CACHE: MUTEX X ==> @ Readme Instructions: @ The patch must be enabled by setting event 12633340 to level 1. It can @ be set in the init.ora or via alter system. If set in the init.ora, @ please note that all events…

当你访问Oracle数据库是若出现ORA-01033 ‘Oracle startup or shutdown in progress’错误,则说明连接到的Oracle实例正在处于一个startup或shutdown的过程中，且该过程尚未结束。 对于此种问题首先要查看alert.log即Oracle告警日志来检查oracle数据库实例是否处于一个startup或shutdown的阻塞状态。 若检查alert.log 后发现，shutdown命令已经在执行但是却hang住了，下面的过程可以帮助你完成shutdown的过程。 1、以SYSDBA身份来连接到问题数据库实例， 必然是以  sqlplus / as sysdba的形式尝试登陆 2、执行shutdown abort命令 3、再次以SYSDBA身份连接到问题数据库实例 ，尝试startup 启动问题数据库实例 注意 这里的shutdown abort是不得已而为之，平时并不推荐使用。 如果上述的shutdown abort过程未能成功将问题解决， 那么一般在Windows上是使用 taskmgr来kill 掉oracle.exe进程， 在Linux/Windows上则可以kill PMON 进程。    

关于JDBC驱动的版本，您可以参考以下文档： How To Determine The Exact JDBC Driver Version (9.x – 11.x) For Standalone Programs [ID 467804.1] 另外请您参考以下文档，该文档介绍了一种导致JDBC程序报告ORA-22990错误的场景： ORA-22990: LOB Locators Cannot Span Transactions ( Doc ID 113666.1 ) The Oracle oracle.sql.BLOB OutputStream writes the data in chunks. Since autocommit defaults to true, the first chunk is committed. This results in the write operation for…

问题的类别   Positioning定位 Pricing定价 Implementation实施 Process处理 Patching打补丁 General Delivery一般递送   后续问题的销售支持联系方式：     定位   问：操作管理operation management与白金服务有什么联系？   答: 在所有ACS服务中，操作管理operation management是建立在白金服务之上。对于Exadata而言，在购买操作管理operation management之前，白金服务是必需的。组件覆盖范围包括：硬件，Exadata软件和Oracle 11g第2版数据库。   问:我的客户目前是SSC的客户，并对这个服务很满意，但他们的Exadata需要操作管理operation management。操作管理operation management是否能代替SSC？   答:操作管理operation management不会取代SSC。这两项服务是兼容的，但同时销售这两个需要你和你的销售支持联系人合作，以减少潜在重叠的服务组件，如账户管理。   问: 我的客户对ACS很陌生。我是否该为他们新的Exadatas或操作管理operation management向他们推荐SSC（或相关的打包服务，例如ASA或白金服务）？   答: 这取决于客户的需求。客户需求一般分为两大类： 想要以现有的雇员管理他们的 Exaadatas的客户。这个情况下，SSC可能是合适的，因为SSC的设计是提供专门的支持资源和积极规划，帮助客户自主管理Exadata，或; 重视特定IT操作，如Exadata的外包的客户。它与之前的数据库设置不同，让许多客户担心会损坏它。如果是这种情况，操作管理operation management可能是合适的选择。 除了以上这些，有些客户可能两者都不适合，这样的话与你的销售支持联系人合作，为你的客户定制正确的解决方案。     问: 当用于Exadata的Auto Service Request (ASR) 自动服务请求被发布，它是否会代替操作管理operation management？   答: 不。ASR 和操作管理operation…

请大家充分利用好当下测试优惠，获取正热的Oracle认证专家认证(OCE) – Oracle数据库12c: 性能管理优化认证。   现在在当期参与Oracle数据库12c性能管理优化测试(1Z0-064)将有50美元的折扣。   除了通过测试外，参与者必须已拥有以下任意一项认证，或者已完成下列Oracle University提供的任意一项培训课程，才有资格获取此认证。   之前已获认证                                             Oracle大学培训课程 ————————-                                     ————————————- Oracle Database 12c Administrator Certified Professional    Oracle Database 12c: New Features for Administrators Oracle Database 11g Performance Tuning Certified Expert   Oracle Database 12c: Backup and Recovery Workshop Oracle Database 12c: Performance Management and Tuning   了解如何使得Oracle数据库12c保持最优性能，获取Oracle数据库12c性能管理和优化认证专家证书。   可通过访问网址pearsonvue.com/oracle注册1Z1-064测试。   您可以从Oracle…

この記事で 症状 原因 解决策 方法   適用範囲： MySQLサーバのバージョン4.0以上 この資料の情報は、すべてのプラットフォームに適用されます。   症状 test.t1をアクセスしてみると，以下のエラが現れる： 150512 16:30:01 [ERROR] MySQL is trying to open a table handle but the .ibd file for table te st/t1 does not exist. Have you deleted the .ibd fil e from the database directory under the MySQL datadir, or have you used DISCARD TABLESPACE?…

適用範囲： MySQLのエンタープライズバックアップバージョン3.5以上 MySQLサーバのバージョン4.0以上 この資料の情報は、すべてのプラットフォームに適用する。   症状 InnoDBエンジンはデータとログファイルのロジクール整合性に頼っている。   InnoDBには予想出来ない行為があるかも知れない。例えば、異なる環境から混ぜたファイル損害についてのシャットダウンとエラ。   エラの例： 2015‐03‐18 11:24:44 11904 [Note] InnoDB: Database was not shutdown normally! 2015‐03‐18 11:24:44 11904 [Note] InnoDB: Starting crash recovery. 2015‐03‐18 11:24:44 11904 [Note] InnoDB: Reading tablespace infor mation from the .ibd files… 2015‐03‐ 18 11:24:44 11904 [ERROR] InnoDB: Attempted to open a previously opened tablespace.…

この記事で 症状 変更 原因 解决策 REPAIR TABLE 人工的にデータファイルを編集する リファレンス   このファイルはOracle Support’s Rapid Visibility (RaV) プロセスで発信するので、独立した技術テストに制約されていない。   適用範囲： MySQLサーバのバージョン4.1以上 この資料の情報は、すべてのプラットフォームに適用されます。   症状 CSV表テーブルをアクセスしてみると、以下のエラが現れた。 ERROR 1194 (HY000): Table ‘t1’ is marked as crashed and should be repaired   テーブルの損害は以上のエラと示せないから。データに損害によって、SELECTも使えるが、こわれたデータが返される。   変更 一般的に、以下の状況が起こったら、現れる： MySQLのシャットダウン：これはオペレーションシステムシャットダウンを含んでいる、例えば電源が切れたなどの状況。 データディレクトリのディスクが足りない。   原因 CSVテーブルがこわれた。前に言ったように、これは非常状態に起こる。   注：SELECT 文が損害で失敗した場合に、INSERT文は実行し続ける。CSVテーブルに対して、行をインサートする。   .CSVがそのテーブルの損害が及ぼす。例えば、テーブルcsvtest.t1の場合、そのファイルは${datadir}/csvtest/t1.CSに${datadir}はMySQLインディクスに使われるデータディレクトリである。損害は常に一行がクリンアップアップされたと見える。それに次の行に同一の列から始まる： 1,”2014-01-11 12:32:22″,”abc” 2,”2014-01-15 13:11:12″,”def”…

  適用範囲： MySQLサーバのバージョン5.5以上 この資料の情報は、すべてのプラットフォームに適用する。 症状 GUIクライアントから関数文法を作成する： CREATE FUNCTION `mydb`.`f_seq_gen` (`applicationid` text) RETURNS INT BEGIN DECLA RE nextval bigint(20); select seqno into nextval from mydb.seqgen where application_id = applicationid; update mydb.se qgen SET seqno = seqno + 1 where application_id = applicationid; RETURN nextval; END   けど失敗した： ERROR 1548 (HY000): Cannot load from mysql.proc. The table…

適用範囲： MySQLサーバのバージョン5.15.1[リリース5.1] MySQLサーバのバージョン4.0以上 この資料の情報は、すべてのプラットフォームに適用する。   症状 電源が切れたからシャットダウンした後、MySQLを起動するときに，以下のエラになった： 130227 11:54:17InnoDB: Assertion failure in thread 4096 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://b ugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, eve n InnoDB: immediately after the mysqld startup, there may be…