{"id":4149,"date":"2022-02-16T19:50:40","date_gmt":"2022-02-16T19:50:40","guid":{"rendered":"https:\/\/nenadnoveljic.com\/blog\/?p=4149"},"modified":"2022-07-05T11:27:25","modified_gmt":"2022-07-05T11:27:25","slug":"data-loss-after-plugging-a-pdb","status":"publish","type":"post","link":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/","title":{"rendered":"Data Loss After Plugging a PDB"},"content":{"rendered":"

Data loss<\/h1>\n

The application started getting ORA-00600 errors on a recently plugged PDB database. As it turned out, it wasn’t an ordinary ORA-00600. This test database couldn’t be rescued and had to be refreshed from the production.<\/p>\n

This problem was insidious – the plug operation itself didn’t return any errors. ORA-00600 started appearing only after the application was running for a while and wanted to query missing data.<\/p>\n

In this article, I’ll describe a scenario of irreversible data loss after plugging a PDB. What’s worse, the data loss can remain unnoticed for a while. Once the application starts failing, it isn’t obvious what’s happening. The ORA-00600 messages are cryptic and don’t tell anything about the root cause. Keep reading if you’re tasked with moving PDBs around – this information can save you a lot of trouble.<\/p>\n

ORA-00600 [25027]<\/h1>\n

We were seeing the following error:<\/p>\n

ORA-00600: internal error code, arguments: [25027], [3], [3], [6],[2667591712<\/span>], [0], [1], [1], [], [], [], []<\/code><\/pre>\n
In particular, the error was appearing when selecting data only from some application tables. The problem was reproducible at will.<\/p>\n
The error was raised on a consistent read (kcbgtcr function is on the stack):<\/p>\n
...\nkrtd2abh_pdb_cursor  call     dbgeEndDDEInvocatio  7F9320B59718 7F931BB45FA8\n()+1780                       nImpl()              7F9320B999C0 7FFD77A76568 ?\n                                                   7F9320B999C0 000000082 ?\nkcbgtcr()+11012      call     krtd2abh_pdb_cursor  7F9320B59718 ? 7F931BB45FA8 ?\n                              ()                   09F003820 ? 7FFD77A76568 ?\n                                                   7F9320B999C0 000000006\nktrget2()+877        call     kcbgtcr()            7F931B405DE8 000000000\n                                                   0000005C4 000000000\n                                                   7F9320B999C0 ? 000000006 ?\nkdirfrs()+1705       call     ktrget2()            7F931B405DD8 ? 7F931B40A578 ?\n                                                   0000005C4 000000000\n                                                   7F9320B999C0 ? 000000006 ?\nqerixFetchFastFullS  call     kdirfrs()            7F931B405DD8 ? 7F931B40A578 ?\ncan()+815                                          0000005C4 ? 000000000 ?\n                                                   7F9320B999C0 ? 000000006 ?\nqerghFetch()+603     call     qerixFetchFastFullS  7F931B405D01 ? 000000000 ?\n                              can()                012D64FE0 7FFD77A815E0\n                                                   000000000 ? 000000006 ?\nqerwnFetch()+16689   call     qerghFetch()         0A31DA108 7F931B404D98\n                                                   003FACBA0 7FFD77A81800\n                                                   000007FFF 0A31DA0C8\nqervwFetch()+166     call     qerwnFetch()         000000000 7F931B44AEE8\n                                                   004060930 7FFD77A819C0\n                                                   000007FFF 0A31DA0C8 ?\nqerwnFetch()+16689   call     qervwFetch()         0A31D8A00 7F931B44B7E8\n                                                   003FACBA0 7FFD77A81AC0\n                                                   000007FFF 0A31DA0C8 ?\nopifch2()+3211       call     qerwnFetch()         000000000 7F931B456E08\n                                                   012ADE300 7FFD77A82080\n                                                   000000001 0A31DA0C8 ?\nkpoal8()+4185        call     opifch2()            000000000 ? 7F931B456E08 ?\n                                                   7FFD77A82440 7FFD77A82080 ?\n                                                   000000001 ? 0A31DA0C8 ?\n...<\/code><\/pre>\n
There are lots of MOS notes with ORA-00600 [25027], mainly for older Oracle releases. None of the published ORA-00600 [25027] bugs seemed relevant for our case. 25027 is probably a value that developers hardcoded to roughly identify the code segment which introduced the error. So I had to focus on other arguments to identify the root cause. The second and the third arguments, [3] and [3], are container id, and [6] is the tablespace id. That’s not enough to narrow down the root cause.<\/p>\n
Therefore, I focused on deciphering 2667591712<\/span>, the fifth argument, which was different for each failed query.<\/p>\n
Consistent read buffer status trace<\/h1>\n
In the course of troubleshooting I discovered the undocumented “consistent read buffer status” trace event, which provided the key information for interpreting the fifth argument:<\/p>\n
ALTER SESSION SET EVENTS='10200 trace name context forever, level 2' ;<\/code><\/pre>\n
oerr ora 10200\n10200, 00000, \"consistent read buffer status\"\n\/\/ *Cause:\n\/\/ *Action:<\/code><\/pre>\n
env [0x7f05457e6f60]: (scn: 0x00000893d2c725cf   xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid:  0x0000.000.00000000  st-scn: 0x0000000000000000  hi-scn: 0x0000000000000000  ma-scn: 0x00000893d2c725c2  flg: 0x00000660)\nktrexf(): returning 9 on:  0x7f054ae96588  cr-scn: 0xffffffffffffffff   xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffffffffffffffff  sfl: 0\nktrgcm(): completed for block  <0x0006 : 0x01823ed5> objd: 0x00045bee\nktrget2(): completed for  block <0x0006 : 0x01823ed5> objd: 0x00045bee\nktrget2(): started for block  <0x0006 : 0x01823ed5> objd: 0x00045bee\nenv [0x7f05457e6f60]: (scn: 0x00000893d2c725cf   xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid:  0x0000.000.00000000  st-scn: 0x0000000000000000  hi-scn: 0x0000000000000000  ma-scn: 0x00000893d2c725c2  flg: 0x00000660)\nktrexf(): returning 9 on:  0x7f054ae96588  cr-scn: 0xffffffffffffffff   xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  cl-scn: 0xffffffffffffffff  sfl: 0\nktrgcm(): completed for block  <0x0006 : 0x01823ed5> objd: 0x00045bee\nktrget2(): completed for  block <0x0006 : 0x01823ed5> objd: 0x00045bee\nktrget2(): started for block  <0x0006 : 0x9f003820<\/span>> objd: 0x00045bee\nenv [0x7f05457e6f60]: (scn: 0x00000893d2c725cf   xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid:  0x0000.000.00000000  st-scn: 0x0000000000000000  hi-scn: 0x0000000000000000  ma-scn: 0x00000893d2c725c2  flg: 0x00000660)\nORA-00600: internal error code, arguments: [25027], [3], [3], [6], [2667591712<\/span>], [0], [1], [1], [], [], [], []<\/code><\/pre>\n
The last accessed block prior to ORA-00600 was the block with the address 0x9f003820<\/span>. This block address indeed matches the fifth argument in the ORA-00600 error message:<\/p>\n
(gdb) p\/x 2667591712<\/span>\n$1 = 0x9f003820<\/span><\/code><\/pre>\n
Block address consists of file_id and block_id.<\/p>\n
block_id is stored in the 22 least significant bits:<\/p>\n
p\/u 0x9f003820<\/span> & 0b1111111111111111111111\n$15983 = 14368<\/span><\/code><\/pre>\n
The file_id is stored in the 10 most significant bits:<\/p>\n
p\/u 0x9f003820<\/span> >> 22\n$15982 = 636<\/span><\/code><\/pre>\n
So the block_id 14368<\/span> in the file_id 636<\/span> is causing the problem.<\/p>\n
Missing file<\/h1>\n
But the file 636<\/span> doesn’t exist:<\/p>\n
select 1 from sys.file$ where relfile# = 636<\/span> ;\n\nno rows selected<\/code><\/pre>\n
However, x$ktfbue, the extent table, has references to this non-existing file:<\/p>\n
select count(*) from x$ktfbue \n  where KTFBUESEGTSN = 6 and KTFBUEFNO = 636<\/span> ;\n\n\n  COUNT(*)\n----------\n        13<\/code><\/pre>\n
There’s also an entry for the requested block in the missing file:<\/p>\n
SQL> select count(*) from x$ktfbue \n  where KTFBUESEGTSN = 6 and KTFBUEFNO = 636<\/span> \n    and 14368<\/span> between KTFBUEBNO and KTFBUEBNO + KTFBUEBLKS -1 ;\n\n  COUNT(*)\n----------\n         1<\/code><\/pre>\n
The following query lists all the missing files:<\/p>\n
select KTFBUESEGTSN ts#, ktfbuefno file# from sys.x$ktfbue\nminus\nselect ts#,relfile# from sys.file$ ; \n\n       TS#      FILE#\n---------- ----------\n         6        636<\/span><\/code><\/pre>\n
The alert log provides the clue about the missing file with the id 636<\/span>:<\/p>\n
Create pluggable database PDB1 using '\/u00\/oracle\/orabase\/admin\/PDB1C\/log\/PDB1_2022-02-09_15_17_28_recover_final.xml' NOCOPY TEMPFILE REUSE\n...\nPDB1(4):Deleting old file#523 from file$\nPDB1(4):Deleting old file#636 from file$<\/span>\n...\nPDB1(4):Adding new file#673 to file$(old file#523).             fopr-0, newblks-720896, oldblks-32768\nPDB1(4):Successfully created internal service PDB1 at open<\/code><\/pre>\n
According to alert log, the plugin operation removed datafiles and added them again under a new file_id. But there wasn’t any “636 added” entry. We checked the directory with datafailes and indeed saw that the file wasn’t there. Now we understood what happened. We didn’t have a manifest when plugging the database. We created it based on the directory with datafiles instead. That manifest was incomplete because the file was missing. Unfortunately, Oracle didn’t raise any error on plugin, so the problem remained unnoticed until the application started to retrieve the missing data.<\/p>\n
Demo<\/h1>\n
I created the tablespace DATA with two small datafiles and the table T, which spread across both datafiles:<\/p>\n
create tablespace data datafile size 5M autoextend off ;\nalter tablespace data add datafile size 5M autoextend off ;\n\ncreate user u no authentication default tablespace data ;\nalter user u quota unlimited on data ;\ngrant create table to u ;\ncreate table u.t (c varchar2(4000));\n\ninsert into u.t select lpad('A',4000,'A') from dual connect by level <= 1000 ;\ncommit;\n\nselect relative_fno,file_id,count(*) from dba_extents where segment_name='T' \n  group by relative_fno,file_id ;\n\nRELATIVE_FNO    FILE_ID   COUNT(*)\n------------ ---------- ----------\n          15         15         19\n          16         16          4\n\nselect file_id, relative_fno, file_name from dba_data_files \n  where tablespace_name = 'DATA' ;\n\n   FILE_ID RELATIVE_FNO\n---------- ------------\nFILE_NAME\n--------------------------------------------------------------------------------\n        15           15\n\/u00\/oracle\/oradata01\/DBER20C\/PDB12\/DBER20C\/D822EC6D95DC3533E0531FE1900A73AD\/da\ntafile\/o1_mf_data_k0sxfg1w_.dbf\n\n        16           16\n\/u00\/oracle\/oradata01\/DBER20C\/PDB12\/DBER20C\/D822EC6D95DC3533E0531FE1900A73AD\/da\ntafile\/o1_mf_data_k0sxfg9f_.dbf\n\nselect ts# from file$ where file# in (15,16);\n\n       TS#\n----------\n         8\n         8<\/code><\/pre>\n
Then, I unplugged the PDB, deleted a file and plugged the database again:<\/p>\n
connect \/ as sysdba\nalter pluggable database PDB12 close ;\n\nALTER PLUGGABLE DATABASE PDB12 UNPLUG INTO '\/tmp\/PDB12.xml' ;\nDROP PLUGGABLE DATABASE PDB12 KEEP DATAFILES; \n\n!rm \/u00\/oracle\/oradata01\/DBER20C\/PDB12\/DBER20C\/D822EC6D95DC3533E0531FE1900A73AD\/datafile\/o1_mf_data_k0sxfg9f_.dbf\n\n!rm \/tmp\/PDB12.xml\n\nbegin\nDBMS_PDB.RECOVER (\n   pdb_descr_file => '\/tmp\/PDB12.xml', \n   pdb_name       => 'PDB12',\n   filenames      => '\/u00\/oracle\/oradata01\/DBER20C\/PDB12\/DBER20C\/D822EC6D95DC3533E0531FE1900A73AD\/datafile\/'\n);\nend ;\n\/<\/code><\/pre>\n
Neither “create pluggable database” nor “database open” raised any errors:<\/p>\n
create pluggable database PDB12 using '\/tmp\/PDB12.xml'\nNOCOPY\nTEMPFILE REUSE;\n\nalter pluggable database PDB12 open ;\n\nalter pluggable database PDB12 close ;\nalter pluggable database PDB12 open ;\n\nalter session set container=PDB12<\/code><\/pre>\n
Expectedly, the deleted file 16 isn’t there:<\/p>\n
select file_id, relative_fno from dba_data_files\nwhere tablespace_name = 'DATA' ;\n\nFILE_ID RELATIVE_FNO\n---------- ------------\n21           15<\/code><\/pre>\n
Alert log<\/h1>\n
The alert log confirms that the file wasn’t added:<\/p>\n
PDB12(4):Buffer Cache flush finished: 4\nCompleted: create pluggable database PDB12 using '\/tmp\/PDB12.xml'\nNOCOPY\nTEMPFILE REUSE\n2022-02-16T14:09:56.495509+01:00\nalter pluggable database PDB12 open\n2022-02-16T14:09:56.498522+01:00\nPDB12(4):Pluggable database PDB12 opening in read write\nPDB12(4):SUPLOG: Initialize PDB SUPLOG SGA, old value 0x0, new value 0x18\nPDB12(4):Autotune of undo retention is turned on.\nPDB12(4):Endian type of dictionary set to little\nPDB12(4):Undo initialization recovery: Parallel FPTR complete: start:2258534527 end:2258534529 diff:2 ms (0.0 seconds)\nPDB12(4):Undo initialization recovery: err:0 start: 2258534527 end: 2258534529 diff: 2 ms (0.0 seconds)\nPDB12(4):[1556525] Successfully onlined Undo Tablespace 2.\nPDB12(4):Undo initialization online undo segments: err:0 start: 2258534529 end: 2258534562 diff: 33 ms (0.0 seconds)\nPDB12(4):Undo initialization finished serial:0 start:2258534527 end:2258534563 diff:36 ms (0.0 seconds)\nPDB12(4):Deleting old file#10 from file$\nPDB12(4):Deleting old file#11 from file$\nPDB12(4):Deleting old file#12 from file$\nPDB12(4):Deleting old file#13 from file$\nPDB12(4):Deleting old file#14 from file$\nPDB12(4):Deleting old file#15 from file$\nPDB12(4):Deleting old file#16 from file$<\/span>\nPDB12(4):Adding new file#20 to file$(old file#10).             fopr-0, newblks-60800, oldblks-16000\nPDB12(4):Adding new file#18 to file$(old file#11).             fopr-0, newblks-25600, oldblks-12800\nPDB12(4):Adding new file#19 to file$(old file#12).             fopr-0, newblks-26880, oldblks-1280\nPDB12(4):Adding new file#17 to file$(old file#13).             fopr-0, newblks-12800, oldblks-12800\nPDB12(4):Adding new file#22 to file$(old file#14).             fopr-0, newblks-12800, oldblks-12800\nPDB12(4):Adding new file#21 to file$(old file#15).             fopr-0, newblks-640, oldblks-640\nPDB12(4):Marking tablespace #7 invalid since it is not present               in the describe file\nPDB12(4):Successfully created internal service PDB12 at open\n****************************************************************<\/code><\/pre>\n
Alert log Lists all deleted and added files. You can compare both lists to identify missing files.<\/p>\n
Extracting file_id and block_id<\/h1>\n
We reproduced the error:<\/p>\n
SQL> select * from u.t ;\nselect * from u.t\n                *\nERROR at line 1:\nORA-00600: internal error code, arguments: [25027], [4], [4], [8], [67108992<\/span>],\n[0], [1], [1], [], [], [], []<\/code><\/pre>\n
ORA-00600 shows the block address. We already learned how to extract the file_id and block_id:<\/p>\n
p\/u 67108992<\/span> >> 22\n16<\/span>\n\np\/u 67108992<\/span> & 0b1111111111111111111111\n128<\/span><\/code><\/pre>\n
Our block is registered in x$ktfbue:<\/p>\n
select count(*) from x$ktfbue \n  where KTFBUESEGTSN = 8 and KTFBUEFNO = 16<\/span>\n    and 128<\/span> between KTFBUEBNO and KTFBUEBNO + KTFBUEBLKS -1 ;\n\n  COUNT(*)\n----------\n         1<\/code><\/pre>\n
Diagnostic query<\/h1>\n
The following query lists the missing datafiles:<\/p>\n
select KTFBUESEGTSN ts#, ktfbuefno file# from sys.x$ktfbue\nminus\nselect ts#,relfile# from sys.file$ ; \n\n       TS#      FILE#\n---------- ----------\n         8         16<\/span><\/code><\/pre>\n
And the following query lists the affected segments:<\/p>\n
SELECT distinct ds.owner, ds.segment_name\n  FROM sys.sys_dba_segs ds, sys.x$ktfbue e\n  WHERE  e.ktfbuesegfno = ds.relative_fno\n    AND e.ktfbuesegbno = ds.header_block\n    AND e.ktfbuesegtsn = ds.tablespace_id\n    AND BITAND (NVL (ds.segment_flags, 0), 1) = 1\n    AND BITAND (NVL (ds.segment_flags, 0), 65536) = 0\n    and e.ktfbuefno not in (select relfile# from sys.file$) ;\n\nOWNER\n--------------------------------------------------------------------------------\nSEGMENT_NAME\n--------------------------------------------------------------------------------\nU\nT<\/code><\/pre>\n
Internals<\/h1>\n
Last but not least, I’ll show how to track consistent reads with debugger.<\/p>\n
Let’s get the the object_id first:<\/p>\n
select object_id, to_char(object_id,'xxxxxxxxx') hex from dba_objects  where object_name = 'T'\n  2  ;\n\n OBJECT_ID HEX\n---------- ----------\n     23968       5da0<\/span><\/code><\/pre>\n
The Oracle C function kcbgtcr does consistent read. It receives the pointer to the structure containing a 64-bit variable that stores the object_id in the 32 most significant bits and the block address in the least 32 significant bits. The following breakpont commands extract the object_id, file_id and block_id and prints them in both decimal and hexadecimal notation (tested on Oracle 19.13 and 19.14):<\/p>\n
b kcbgtcr\ncommands 1\nset $value = *(long *)($rdi+0x4)\nset $object_id = $value>>32\nprintf \"object_id: 0x%x %u\\n\", $object_id, $object_id\nset $file_id = ( $value & 0x00000000ffffffff ) >> 22\nprintf \"file_id: 0x%x %u\\n\", $file_id, $file_id\nset $block_id = $value & 0b1111111111111111111111\nprintf \"block_id: 0x%x %u\\n\", $block_id, $block_id\nend<\/code><\/pre>\n
You’ll hit the breakpoint for every fetched row:<\/p>\n
Breakpoint 1, 0x00000000129d3250 in kcbgtcr ()\nobject_id: 0x5da0 23968<\/span>\nfile_id: 0xf 15\nblock_id: 0x82 130<\/code><\/pre>\n
If the affected table contains many rows, and you would like to hit the breakpoint only on missing block read attempt, you can setup the following condition:<\/p>\n
cond 2  ( ( *(long *)($rdi+0x4) & 0x00000000ffffffff ) >> 22 ) == 16<\/span> && ( *(long *)($rdi+0x4) & 0b1111111111111111111111 ) == 128<\/span><\/code><\/pre>\n
object_id: 0x5da0 23968<\/span>\nfile_id: 0x10 16<\/span>\nblock_id: 0x80 128<\/span><\/code><\/pre>\n
Conclusion<\/h1>\n
You have to be extremely careful when plugging a PDB, especially if you don’t have a reliable manifest. When a datafile is missing, the operation “succeeds”, i.e. it doesn’t raise any errors. However, there will be a data loss, which might remain unnoticed for a while. The sessions will get a cryptic ORA-00600 when trying to access missing data.<\/p>\n
Therefore, you might want to test plugging first, especially if the PDB was unplugged by someone else. There are two checks you can do on your own. One is comparing the lists of the deleted and added file_ids in the alert log. The other is querying the missing files from undocumented data dictionary tables.<\/p>\n
Updates<\/h1>\n
May 27, 2022<\/h2>\n
After 3+ months of back and forth, Oracle support concluded it’s expected behavior after a user error. Handle with care \ud83d\ude42<\/p>\n
July 5, 2022<\/h2>\n
Oracle support filed the following bug:
\nBug 34318403 – ORA-0600 ERROR DURING PDB PLUG-IN WHEN DATAFILE IS REMOVED<\/p>\n","protected":false},"excerpt":{"rendered":"
ORA-00600 [25027] in PDB. Tracing buffer reads. kcbgtcr Oracle C function. Continue Reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[25,51,5],"tags":[],"class_list":["post-4149","post","type-post","status-publish","format-standard","hentry","category-corruption","category-ora-00600","category-oracle"],"yoast_head":"\nData Loss After Plugging a PDB - All-round Database Topics<\/title>\n<meta name=\"description\" content=\"ORA-00600 [25027] in PDB. Tracing buffer reads. kcbgtcr Oracle C function.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Data Loss After Plugging a PDB - All-round Database Topics\" \/>\n<meta property=\"og:description\" content=\"ORA-00600 [25027] in PDB. Tracing buffer reads. kcbgtcr Oracle C function.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/\" \/>\n<meta property=\"og:site_name\" content=\"All-round Database Topics\" \/>\n<meta property=\"article:published_time\" content=\"2022-02-16T19:50:40+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-07-05T11:27:25+00:00\" \/>\n<meta name=\"author\" content=\"Nenad Noveljic\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@NenadNoveljic\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Nenad Noveljic\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/\"},\"author\":{\"name\":\"Nenad Noveljic\",\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/#\\\/schema\\\/person\\\/51458d9dd86dbbdd19f5add451d44efa\"},\"headline\":\"Data Loss After Plugging a PDB\",\"datePublished\":\"2022-02-16T19:50:40+00:00\",\"dateModified\":\"2022-07-05T11:27:25+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/\"},\"wordCount\":945,\"commentCount\":11,\"articleSection\":[\"corruption\",\"ORA-00600\",\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/\",\"url\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/\",\"name\":\"Data Loss After Plugging a PDB - All-round Database Topics\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/#website\"},\"datePublished\":\"2022-02-16T19:50:40+00:00\",\"dateModified\":\"2022-07-05T11:27:25+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/#\\\/schema\\\/person\\\/51458d9dd86dbbdd19f5add451d44efa\"},\"description\":\"ORA-00600 [25027] in PDB. Tracing buffer reads. kcbgtcr Oracle C function.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/data-loss-after-plugging-a-pdb\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Data Loss After Plugging a PDB\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/\",\"name\":\"All-round Database Topics\",\"description\":\"Nenad Noveljic\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/#\\\/schema\\\/person\\\/51458d9dd86dbbdd19f5add451d44efa\",\"name\":\"Nenad Noveljic\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97b796613ea48ec8a7b79c8ffe1c685dcffc920c68121f6238d5caab5070670?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97b796613ea48ec8a7b79c8ffe1c685dcffc920c68121f6238d5caab5070670?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a97b796613ea48ec8a7b79c8ffe1c685dcffc920c68121f6238d5caab5070670?s=96&d=mm&r=g\",\"caption\":\"Nenad Noveljic\"},\"sameAs\":[\"nenad-noveljic-9b746a6\",\"https:\\\/\\\/x.com\\\/NenadNoveljic\"],\"url\":\"https:\\\/\\\/nenadnoveljic.com\\\/blog\\\/author\\\/nenad\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Data Loss After Plugging a PDB - All-round Database Topics","description":"ORA-00600 [25027] in PDB. Tracing buffer reads. kcbgtcr Oracle C function.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/","og_locale":"en_US","og_type":"article","og_title":"Data Loss After Plugging a PDB - All-round Database Topics","og_description":"ORA-00600 [25027] in PDB. Tracing buffer reads. kcbgtcr Oracle C function.","og_url":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/","og_site_name":"All-round Database Topics","article_published_time":"2022-02-16T19:50:40+00:00","article_modified_time":"2022-07-05T11:27:25+00:00","author":"Nenad Noveljic","twitter_card":"summary_large_image","twitter_creator":"@NenadNoveljic","twitter_misc":{"Written by":"Nenad Noveljic","Est. reading time":"9 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/#article","isPartOf":{"@id":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/"},"author":{"name":"Nenad Noveljic","@id":"https:\/\/nenadnoveljic.com\/blog\/#\/schema\/person\/51458d9dd86dbbdd19f5add451d44efa"},"headline":"Data Loss After Plugging a PDB","datePublished":"2022-02-16T19:50:40+00:00","dateModified":"2022-07-05T11:27:25+00:00","mainEntityOfPage":{"@id":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/"},"wordCount":945,"commentCount":11,"articleSection":["corruption","ORA-00600","Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/","url":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/","name":"Data Loss After Plugging a PDB - All-round Database Topics","isPartOf":{"@id":"https:\/\/nenadnoveljic.com\/blog\/#website"},"datePublished":"2022-02-16T19:50:40+00:00","dateModified":"2022-07-05T11:27:25+00:00","author":{"@id":"https:\/\/nenadnoveljic.com\/blog\/#\/schema\/person\/51458d9dd86dbbdd19f5add451d44efa"},"description":"ORA-00600 [25027] in PDB. Tracing buffer reads. kcbgtcr Oracle C function.","breadcrumb":{"@id":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/nenadnoveljic.com\/blog\/data-loss-after-plugging-a-pdb\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/nenadnoveljic.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Data Loss After Plugging a PDB"}]},{"@type":"WebSite","@id":"https:\/\/nenadnoveljic.com\/blog\/#website","url":"https:\/\/nenadnoveljic.com\/blog\/","name":"All-round Database Topics","description":"Nenad Noveljic","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/nenadnoveljic.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/nenadnoveljic.com\/blog\/#\/schema\/person\/51458d9dd86dbbdd19f5add451d44efa","name":"Nenad Noveljic","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a97b796613ea48ec8a7b79c8ffe1c685dcffc920c68121f6238d5caab5070670?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/a97b796613ea48ec8a7b79c8ffe1c685dcffc920c68121f6238d5caab5070670?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a97b796613ea48ec8a7b79c8ffe1c685dcffc920c68121f6238d5caab5070670?s=96&d=mm&r=g","caption":"Nenad Noveljic"},"sameAs":["nenad-noveljic-9b746a6","https:\/\/x.com\/NenadNoveljic"],"url":"https:\/\/nenadnoveljic.com\/blog\/author\/nenad\/"}]}},"_links":{"self":[{"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/posts\/4149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/comments?post=4149"}],"version-history":[{"count":2,"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/posts\/4149\/revisions"}],"predecessor-version":[{"id":4285,"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/posts\/4149\/revisions\/4285"}],"wp:attachment":[{"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/media?parent=4149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/categories?post=4149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nenadnoveljic.com\/blog\/wp-json\/wp\/v2\/tags?post=4149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}