Bug 12633340 – RISK SESSION SPIKE – LIBRARY CACHE LOCK AND LIBRARY CACHE: MUTEX X

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 must be specified on consecutive lines. If
@ set via alter system, it will take effect only for new sessions
@ that connect after that point in time.
@ .
@ event=”12633340 trace name context forever, level 1″
@ .
@ This patch amends an earlier fix that was made in bug 6769075. Due to
@ that fix, cursor reloads may take longer in a highly concurrent environment
@ if that cursor was invalidated due to a DDL operation. With this patch,
@ the reload issue should be fixed and it should resolve the related mutex
@ contention. Note that this patch is not meant to eliminate all mutex
@ contention in general. It should however eliminate or minimize mutex
@ and library cache lock waits associated with the “build lock” for
@ the cursor after DDL has occurred.

Bug 16870682 – ESSC: LIBRARY CACHE LOCK 60%, MUTEX X 20%, CONCURRENT DDL, DML, Q ON PT
==>
@ I would say all three changes helped but is mostly the event 12633340, level
@ 4 which seems to have the greatest share

如何处理ORA-01333 ‘Oracle startup or shutdown in progress’错误

当你访问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 进程。

 

 

ORA-22990: LOB 定位符无法扩展事务处理

关于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 the next chunk of the Blob to fail since it appears to be in the next transaction.
In those conditions, the ORA-22990 exception will occur with any version of Oracle JDBC driver.

Oracle oracle.sql.BLOB OutputStream对象以分块(chunk)的方式写数据。因为autocommit参数默认是true,如果第一个chunk提交,会导致写下一个chunk失败,因为该操作已经走到了下一个事务。这种情况下JDBC驱动会报告ORA-2290。

该问题的解决方法是,在connection中开始设置setAutoCommit为false。在所有的chunck都写完后,最后调用stream.close()来进行提交。

您的代码中使用的是Clob,但是该文档也可能适用。您可以参考文档修改您的代码,在执行sql之前调用conn.setAutoCommit(false), 然后在数据全部完成之后调用writer.close()。

为了能继续分析此问题,请您提供以下信息:
1. JDBC驱动的具体版本,请您参考之前我们提供的文档检查JDBC驱动的版本。

2. ORA-22990发生的原因是由于transaction发生了变化。在另外一个文档中记录了由于在在事务进行过程中,物理连接的变化导致的ORA-22990。
在整个transaction开始到commit期间,jdbc使用的物理连接是不能变的。如果您使用了连接池,请您检查连接池是否有可能在事务执行期间更换物理连接。
例如WebLogic Server的连接池提供了KeepXAConnTillTxComplete参数来保证XA Transaction从始至终使用同一物理连接,来避免该问题。

 

高级客户服务 Oracle Exadata 服务 FAQ

问题的类别

 

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或白金服务)?

 

: 这取决于客户的需求。客户需求一般分为两大类:

  1. 想要以现有的雇员管理他们的 Exaadatas的客户。这个情况下,SSC可能是合适的,因为SSC的设计是提供专门的支持资源和积极规划,帮助客户自主管理Exadata,或;
  2. 重视特定IT操作,如Exadata的外包的客户。它与之前的数据库设置不同,让许多客户担心会损坏它。如果是这种情况,操作管理operation management可能是合适的选择。

除了以上这些,有些客户可能两者都不适合,这样的话与你的销售支持联系人合作,为你的客户定制正确的解决方案。

 

 

: 当用于ExadataAuto Service Request (ASR) 自动服务请求被发布,它是否会代替操作管理operation management

 

: 不。ASR 和操作管理operation management是兼容的。

ASR是:

  1. Premier Support的一部分,以及;
  2. 当这些 FRUs故障或达到预定的超出正常范围的操作限值时,对在Exadata中指定字段可替换单元(FRUs)的有价值的call home函数 。在满足其中一个条件的事件中,如果客户还没有注意到问题,ASR “phones home” 可以通过发出替换这些预定的FRU的SR,缩短支持过程。

ASR 不是:

  1. 在Exadata上目前可用,虽然它预计将很快面世,但需要当前Exadata客户的支持的升级
  2. 与 Oracle Configuration Manager (OCM)集成
  3. Exadata的完整监控解决方案

 

Operations Management建立在ASR之上,与ACS的整体定位一致。 ASR遥测是更丰富的一套定制的硬件,环境,软件和数据库的遥测的一部分,由Operations Management用于理解的整个Exadata堆栈的整体健康和性​​能。只有Operations Management有从数据库层到网络层的集成的完整的堆栈监控功能。更重要的是,Operations Management与ASR是功能分离的,因为ASR在损坏时加速修复的支持服务功能,而Operations Management有充分全天候管理Exadata的责任,与系统和数据库管理员相同。

 

: 那么,ExadataExadata季度丁部署Operations Management是如何运作的

 

: Operations Management包括季度补丁部署。补丁服务只提供客户季度Exadata的统一补丁的部署,其中包括硬件,固件,软件和数据库补丁。冗余的费用,如连接建立,账户管理时间和门户网站设置只有当包括Operations Management时才会从Patching Service的假设中删除。

定价

 

: 我如何定价Exadata Oracle Operations Management?

 

: 有两种定价Oracle Operations Management 交易的方式。对于小型交易,这里是第一个实例的价格:

price_management_monitoring

 

  • 小于$500,000的交易使用这些价格
  • 你会在1个工作日以内获得回复。
  • 请提供以下信息:
    • Exadatas将要部署的国家
    • 按国家的网站编号/位置
    • 按网址/位置的Exadata编号
    • 每个ExadataRack 大小和磁盘类型

 

  • 对于所有大型交易 (3个系统以上), 非标准交易如非英语交付(法语, 西班牙语,德语) 或根据国家的交付资源 (除了印度) 或定制配置

 

: 我如何定价,获得包含远程和现场资源的Ops Mgt交易的批准和合同?

 

: 参见以上指南,了解回答b中的非标准交易。

 

: 我有一个有多个rack非常大的Exadata。由于增长的经济,我是否可以得到更大的定价折扣?

 

: ACS Pricing Wizard 将所有大于 $500,000 的交易标志为需要定制定价。在这里,定价是由Operations Management业务送货人员给出的人力估算工具完成的。他们会将交易的各方面综合考虑,基于对帐户和交易的整体规模的了解,决定最有可能的价格。使用以上的bid desk alias。

 

: 是否可以监测SLA定价什么影响?

 

:监控的SLA是标准的且没有降价。

 

: 如果客提供了自己的DBA,他是否可以删除IT架构交付从而金?

 

:这个做法的节省是微不足道的,且应避免这种交易。我们可以与客户共享数据库管理职责,但Oracle作为责任的单点,他们最好保持服务紧密捆绑在一起为一体的产品。

 

: 什么非生Exadata机架成本相同?我是否可以得到一个非生的折扣?

 

: 很少。一直以来,我们的经验是,测试和开发系统需要相同工时作为生产系统进行监控,管理。如果有其他可减轻的情况,请让销售支持参与。

 

: 我的客户计在他们Exadata上放置大于标准数量的数据库= 2 / 四分之一机架4 /半机架,8 /全机架)是否更

 

: 是的,这将花费更多。这取决于正在实施的额外数据库的数量和其他的非标准变化。请与bid desk合作,以确定修改后的价格。

 

实施

 

: I understand a new “box” is necessary at the customer site. Is it one box per machine or one box per customer site? 我知道在客户站点有一个box”是必要的到底是一台机器一个盒子还是一个客户站点

 

: . 这个盒子被称为“Oracle Operations Management Gateway”。我们需要一个每个站点有一个(或更具体地每个网络有一个),所以如果一个box在相同的网络上,就能为多个位置提供服务。一般我们建议如果有多个位置配置两个box。

 

 

: 将安装个新的盒子Oracle Operations Management Gateway)?

 

:  Oracle Operations Management Gateway出厂时预先配置,并设计为客户安装。我们只需要电源,网络配置和防火墙的访问,然后就可以远程进行其余的安装。在事件中,如果客户不想自己安装,甲骨文的人员可以来现场。

 

: 我的客是一家大型金融机构。他需要管理Exadata帮助,但他有极其格的有关访问的安全政策我还有必要告诉这个服务吗

 

: Yes. Operations Management is both a highly flexible and secure service delivery model by design. Operations Management has very large customer in the US, European and Asian in the Financial, Healthcare and Government verticals. These customers have tailored security access process or in some cases purely on-site delivery models. Remote security compliance customization can include inbound access only on demand or with other limitations compliant with the customer requirements. But always bear in mind the security basics with any customer: 是的。Operations Management的设计是既高度灵活又安全的服务提供模式。Operations Management在美国,欧洲和亚洲,在金融,医疗保健和政府方面有大量的客户。这些客户有定制的安全访问过程或在某些情况下,纯粹的现场交付模式。远程安全合规性、的定制在按需或符合客户要求的其他限制下包括入站访问。但是,始终牢记对于任何客户的安全基本知识:

  1. 我们从不访问客户数据,只需要管理客户系统的元数据,以及;
  2. 我们对所有全球交付位置都进行 ISO 27001 认证,以及;
  3. 所有交付人员都经过筛选;
  4. 所有访问通过高度安全过程,包括密码验证被执行,同时也被记录和跟踪。

 

: 我知道远程Operations Management非常安全,但这并不重要。远程访问对我的客户是一个非首发,但他们想要一个托管的服务,我们有什么其他可销售的吗?

 

: 是的。有两个主要选项:

  1. 如果客户真的不愿接受任何连接,甚至只是站外连接,那么我们会提供现场的资源。转移覆盖,客户人员的整合,流程和工具都可以在此模型中定制。同样,现场工作人员可以追求所需的相应安全许可。
  2. 你可能已经涉及这个,但它值得一提,因为它可以使现场工作人员更有效,并给你的客户一个更经济的选择:如果客户允许仅站外连接,你可以对所有必要的访问提供有限的上门交付资源的混合模式,而无需工作人员每天3班。

 

过程

 

: 我知道 ”是全天候的,所有的事件都记录为务请求,然后将其传递给有没有其他通知机制可用?

 

: 客户当然可以给我们打电话或发送电子邮件,或通过Orion放置SR,但通常是我们通知他们。他们可以通过Operations Management Portal查看一切。他们还可以通过登录门户网站的记录事件,如果他们想的话。

 

: 如果客户只购买MON,服务会为客户在MOSMy Oracle Support中初始化SR创建 (假设决定15分钟通知SLA的激活事件发生)
: 在MON(仅监控)的合同中,当警报被触发,它被发送到我们​​的Operations Management控制中心,并在同一时间,一个ASR(自动服务请求)被Oracle Premier Support启动。我们向客户通知事件,并给了他们Incident Ticket。在这时,客户的工作是协调问题的缓解。如果在一个MAN(管理)的合同中,我们将保留turn-key责任,以解决该问题。

 

: 当我通知客户MON水平服务以下的事件会被提供什么级别细节?且他如何
:我们进行适当的客户通知联系,通常是通过电子邮件或电话,并提供Incident Ticket号。在ticket中,我们记录在警报中接收到的所有相关信息,以及Oracle Support SR号(如果适用)。

 

打补丁

 

 

: 如果客使用的是Exadata DBM提供独立的开测试UATQA境,是否可以独立地升级测试补丁程序的影响?

 

:  Quarterly Patching包被设计为一次性滚动到机架中的所有组件。从理论上讲,我们可以分离补丁以滚到测试/开发数据库实例,但是做到这一点就会加倍工时。在这样的情况下,我们将需要评估额外的工作级别并应用附加费。

 

:季度丁服相关的测试过是什么

 

: The primary value of the service is that the patch bundle has already been tested by SSC on complete Exadata machines.  We will not be replicating a customer environment and re-testing prior to roll-out.  Of course if the customer has a separate test/dev Exadata rack, we would apply it there prior to a production roll-out.  该服务的主要价值在于补丁包已经在完整的Exadata机器通过SSC测试。我们不会复制客户环境并在转出之前重新测试,转出。当然,如果客户有一个单独的测试/开发数据库Exadata机架,我们会生产转出之前在应用它。

 

一般递送

 

:该服务只提供数据库层的管理?

 

: 不。该服务是基于Sun和Oracle监视和管理工具的集成。Exadata一切都被控和管理,即使不支持SNMP数据(最常用于监视IT设备中的信息)的Infiniband交换机经由日志文件跟踪。该服务在行业内和Oracle中是唯一的,因为它聚集Oracle Enterprise Manager,Integrated Lights Out Management(ILOM),Auto Service Request(ASR)和自定义脚本,如对于机架内环境监测到单个无缝监控和管理提供。

 

:对于“24×7Predictive Monitoring预测监控”的定义是什么?

 

:  服务是一天24小时,每周7天提供的,并且是自动和预测的。在报警的情况下,我们会以我们的知识数据库中的信息自动匹配它,并采取行动,以确保最小或对客户没有影响。

 

: “数据库和存储配置”的定义是什么?

 

: 我们将代表客户配置和管理对环境的所有改变,即我们承担实际DBA和存储配置的工作 – 客户不需要做任何事情。

 

: 客户已经使用OEM Grid Control,它与“监控”是否兼容?有哪些影响?

 

: 是的我们的服务是兼容的。这样的客户将需要额外的步骤来评估最佳的执行配置,但这不会影响定价和交付能力。

 

: When packaged with an ASA or a BCA service, is it possible to just have Operations  “monitoring” on: 当与一个ASABCA服务打包,只有操作在“监控”可能吗:

 

  • 服务器和/
  • 操作系统和/
  • 存储和/
  • RDBMS

 

 

: 只购买监测和再单独卖ASA或BCA服务是可以的。独立监视或管理可以为Oracle Exadata IT栈(hw/os/db/storage)的任何或所有部件提供。但对客户来说,出售整个打包的Oracle Operations Monitoring或Exadata 解决方案的管理会带来最佳效益。取消捆绑消除了提供服务的协同作用,并会消除经济利益,如嵌入式季度补丁服务。

 

 

: 在林利斯戈,苏格兰有没有讲法语的人?这是否意味着,如果需要或现场参观的话,客户可以在法国与我们的ACS操作管理operation management控制中心通过电话互动?

 

: Oui, Oui/ 是的。我们有本地讲法语,德语和西班牙语的人。我们也支持10种其他语言,本地或是通过国外翻译POP。

 

 

: BCA Operations Management 门户相同吗?

 

: BCA 和Operations Management 是不同的服务,各自有唯一的门户。ACS Operations Management Portal 同时提供管理和各户对所有配置,事件,问题,变更管理报告以及基本系统性能报告的可见性的监控。

 

: 我的顾客喜欢Operations Management的理念,我们看了他的幻灯片和合同,但他们想知道具体有哪些操作且服务监控些什么。我在哪里可以得到这个信息?

 

: Activities are based in the ITILv3 process. A demo of the portal and sample account reviews should help 答 customer 问s about activates. Specific monitoring KPIs are available via your sales support contact. They are not generally available because they are continuously updated to improve service therefore must not be locked down in a contract. 活动在ITILV3过程中。门户和示例账户审查的演示将有助于回答客户关于激活的问题。具体的监测KPI是可以通过你的销售支持联系人获取。它们一般不可用,因为它们被持续更新以提高服务,因此不能在合同中被锁定。

 

所有其他ACS Exadata服务

 

定价

 

: 如果我3完整机架,定价向为红色,如所示。只有配置估和丁管理服机架数量敏感的其他组件的质量户门户机架数量,保持不是否所有的都要机架敏感

 

: No. Customer Orientation and Training, Customer Portal and Connectivity Set Up are among the components which are constant regardless of how many racks are purchased. Which service components do and do not change depending on the number of racks is built into the pricing wizard. 不。客户导向和培训,客户门户和连接设置在组件中是不变的,无论有多少购买的机架。哪些服务组件是否更改取决于定价向导中内置的机架的数量。

 

 

实施

 

: 我知道对于存储有特定的Exadata件。这需要收取外的配置服务费

 

: 不。Exadata是作为数据配置服的一部分被配置的

数据库性能优化 – Oracle数据库12c性能管理优化认证

请大家充分利用好当下测试优惠,获取正热的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 Certification网站上获取所有相关详细准备信息,包括考试目标,题目数量,考试时间分配及测试价格。

 

相关链接:

认证路线: Oracle Certified Expert, Oracle Database 12c: Performance Management and Tuning

测试科目: Oracle Database 12c: Performance Management and Tuning exam (1Z0-064)

相关网址: About Beta Exams

测试注册: Pearson VUE

MySQL InnoDB テーブルが壊れて、このようなエラが現れた: “MySQL is trying to open a table handle but the .ibd file for table ### does not exist”

この記事で

症状

原因

解决策

方法

 

適用範囲:

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?

See http://dev.mysql.com/doc/refman/5.1/en/innodb‐troubl eshooting.html

how you can resolve the problem.

 

原因

このエラの原因はテーブルt1の.ibdファイルがないからである。これはどんな文でもテーブルT1に対して実行出来ない。

エラ自身でそしてそのファイルがまだ存在しているかを確認する:

shell> ls ‐lahR /var/lib/mysql/

/var/lib/mysql/test:

total 21G

drwx‐‐‐‐‐‐ 2 mysql mysql 32K may 12 03:55 .

drwxr‐xr‐x 7 mysql mysql 4,0K nov 10 2014 ..

‐rw‐rw‐‐‐‐ 1 mysql mysql 8,6K may 12 03:16 t.frm

‐rw‐rw‐‐‐‐ 1 mysql mysql 20M may 12 13:37 t.ibd

‐rw‐rw‐‐‐‐ 1 mysql mysql 8,5K ago 10 2014 t1.frm

‐rw‐rw‐‐‐‐ 1 mysql mysql 8,5K may 12 03:16 t2.frm

‐rw‐rw‐‐‐‐ 1 mysql mysql 128K may 12 03:16 t2.ibd

もう一度MySQLエラログを確認して、エラが現れるときに、つまり、truncate tableを実行しているときに見られる。その文は自身の.ibdファイルを再構造できないから、ファイルがなくした:

140810 5:05:03 InnoDB: TRUNCATE TABLE test/t1 failed to create a new

tablespace

 

解决策

テーブルを再構造する:

  1. Drop table:

mysql> DROP TABLE test.t1;

The following error may be seen in the error log afterwards, but it’s basically saying the

tablespace was still present in InnoDB Data Dictionary and that eventually was removed:

150513 14:49:08 InnoDB: Error: table ‘test/t1’

InnoDB: in InnoDB data dictionary has tables pace id 607381,

InnoDB: but tablespace with that id or name does not exist. Have

InnoDB: you deleted or moved .ibd files?

InnoDB: This may also be a table created with CREATE TEMPORARY TABLE

InnoDB: whose .ibd and .frm files MySQL automatically removed, but t he

InnoDB: table still exists in the InnoDB internal data dictionary.

InnoDB: Please refer to

InnoDB: http://dev.mysql .com/doc/refman/5.1/en/innodb‐troubleshootingdatadict.

html

InnoDB: fo r how to resolve the issue.

InnoDB: We removed now the InnoDB int ernal data dictionary entry

InnoDB: of table `test`.`t1`.

 

  1. 再びCreate table
  2. テーブルのアクセスをテストして、実行できるかを確かめる。 (ex: optimize table)

mysql> OPTIMIZE TABLE test.t1;

 

MYSQL 物理バックアップが空けたデータディレクトリも複数のInnoDB損害あるいはシャットダウンする

適用範囲:
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. Previous tablespace test/t uses space ID: 3695 at filepath: ./test/t.ibd.

Cannot open tablespace test/#sql2‐1ab0‐5 which uses space ID: 3695 at filepath:

./test/#sql2‐1ab0‐5.ibd

2015‐03‐18 11:24:44 7fe 914a04720 InnoDB: Operating system error number 2 in a file

operation.

InnoDB: Th e error means the system cannot find the path specified.

InnoDB: If you are installing InnoDB, remember that you must creat e

InnoDB: directories yourself, InnoDB does not create them.

InnoDB: Error: could not open single‐table tablespace file ./test/#sql2‐1ab0‐5.ibd

 

原因

バックアップが古いInnoDBデータあるいはログファイルのディレクトリにリカバリした。

 

解决策

InnoDBファイルを整合性を確保する方法はバックアップを空けたディレクトリにリカバリすることである。

 

MySQL Enterprise Backup (MEB) – リカバリする:

Important

  • ある完全なリカバリを実行する時に(例えば、バックアップデータを新しいMySQLサーバに使われる時。あるいは今のMySQLサーバすべてのデータを交換するとき。)目標データは古いデータファイルあるいはいらないデータファイルを含んでいないことを確保してください。(これは人工的にファイル位置を削除する必要があるかも知れない。– datadir と –innodb_data_file_path二つのオプションを使ってください);さもなければ、–forceオプションをrestoreコマンドで古いデータを上書きされる。コマンドは古いデータを上書きする。使用–use-ttsオプションで作成されたバックアップリカバリは同じクリンアップが必要としていない。リカバリする部分に対して、わざわざバックアップする必要がない。

MySQL CSV Table is Marked as Crashed and Should be Repaired; Corrupted or Mangled Data; Error 1194

この記事で

症状

変更

原因

解决策

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”

3,”20144,”2014-01-28 18:00:19″,”jkl”

5,”2014-02-04 12:49:30″,”mno”

6,”2014-02-04 13:22:25″,”pqr”

 

前のインディクスで第三行がこわれた、そして二つの部分を含んでいる:

  • 3,”2014

これはクリンアップされた行である

  • 4,”2014-01-28 18:00:19″,”jkl”

これは次の行

 

解决策

解決策が二つの方法がある:

REPAIR TABLEを使ってください

人工的にデータファイルを編集する

 

REPAIR TABLE

REPAIR TABLEコマンドは一番簡単な方法だが、テーブルがシャットダウンと標識されたときだけにこのコマンドを実行できる。実行方法は損害が発生する前にデータファイルをクリンアップする:

REPAIR TABLE csvtest.t1;

 

アラーム: REPAIR TABLE for a CSV table は初めての行を見つけたら、テーブルをクリンアップするので、データがなくなる!

 

人工的にデータファイルを編集する

ファイルエディタで人工的にテーブルのこわれた部分を削除することで、データファイルを編集できる例えば以上のインディクスによって、ファイルを変更できる:

1,”2014-01-11 12:32:22″,”abc”

2,”2014-01-15 13:11:12″,”def”

4,”2014-01-28 18:00:19″,”jkl”

5,”2014-02-04 12:49:30″,”mno”

6,”2014-02-04 13:22:25″,”pqr”

 

データファイルのコピを実行することを勧めている。

 

この方法のメリットは这种方法的优点是,你必须改变更细粒度的控制,例如上述更改,仅行id=3将丢失,而不是id> =3的所有行。

 

データファイルをコピするには以下の通りステージを使ってください(LinuxあるいはUnix;似たようなステップWindowsに利用できる)csvtest と t1をテーブルのデータベースと名前を代わってもいい:

  1. mysql> LOCK TABLES csvtest.t1 WRITE;
  2. mysql> FLUSH TABLES csvtest.t1;
  3. shell$ ls ‐l /var/lib/msyql/csvtest/t1.CSV
  4. shell$ cp /tmp/t1.CSV /var/lib/msyql/csvtest/t1.CSV
  5. Make sure the /var/lib/msyql/csvtest/t1.CSV has the same owner and access permissions as found

in step 3.

  1. mysql> UNLOCK TABLES;
  2. mysql> SELECT * FROM csvtest.t1 WHERE id = 6;

 

ステップ7.のクエリでCSVファイルを最後の行を見つけ出せるを確認する。

MySQL作成関数はError 1548のせいで失敗した

 

適用範囲:
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 is probably

corrupted

 

原因

テーブルmysql.procがこわれたあるいはテーブル構造が違っている。

一般的に、これは違ったバーションのアップグレードやダンプ/リカバリによるものである。

 

解决策

まずは:

CHECK TABLE `mysql`.`proc` EXTENDED;

REPAIR TABLE `mysql`.`proc`;

 

そして格納した関数を再構造する。

 

失敗した場合は、テーブル構造が違っている可能性が大きいである。

 

解決策は以下の通りを実行して

mysql_upgrade ‐uroot ‐‐force ‐p

システムテーブルを正確な構造に戻る。

 

もしすべてのデータテーブルを検索したくなければ(時間をかかりすぎ),オプションupgradesystemtablesを指定してください。

 

MySQL Server Crash: “InnoDB: Error: trying to access page number … which is outside the tablespace bounds.”

適用範囲:

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

InnoDB: corruption in the InnoDB tablespace. Please refer t o

InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing‐recov ery.html

InnoDB: about forcing recovery.

130227 11:54:17 ‐ mysqld got si gnal 11 ;

 

原因

これはInnoDBがファイルシステムレベルのデータファイルがこわれたからである。

 

注意事項

オペレーションシステムあるいは一部のディスクハードウェアが誤ったことをflushtodiskオペレーションに報告するかもしれない。mysqld flushが起こったと報告した、実際には起こっていない。それでディスクに書き込むときによく変化があるので、最悪の場合、電源が切れたから、InnoDBデータベースがこわれる。SCSIディスクコントローラーあるいはもともとディスクにあるバック電池が持っているディスク高速メモリーでファイルフラシュを加速する。

 

解决策

以下のステップでリカバリできる:

  1. MySQLが閉められて、すべてのデータベースファイルをコピすることでバックアップを作成する。これは大事なことなんだから、innodb_force_recoveryを使ったら、また損害がひどくなる。
  2. innodb_force_recoveryを実行した状態でMySQLを起動する。大きいな数値が必要になるかもしれない、リカバリモードで、できるだけ多くのデータをダンプしてください。そのあとInnoDBを初期化することを確保してください。このプロセスはこのガイドブックに記されている:Starting

InnoDB on a Corrupted Database.

  1. バックアップからリカバリする。一般的に、これは唯一成功できる方法である。もしこの方法を選んでいれば、まずはこわれたファイルのバックアップを作成して、それからデータをリカバリする。

 

沪ICP备14014813号-2

沪公网安备 31010802001379号